Ubuntu на VPS становится безразличной: ОШИБКА: мягкий тупик - CPU#0, застрявший в 22

У нас есть VPS под управлением Ubuntu на Xen. Проблема - это, об один раз в день, в течение приблизительно 20-50 минут, в случайное время, сервер становится абсолютно безразличным к внешнему миру. После этого периода это становится быстро реагирующим снова, как будто ничего не произошло, это не теряет время работы, это не перезапускает. Это только начинает отвечать снова, как будто это было в анабиозе.

Эти отключения электричества происходят при условиях неисключительной памяти и CPU, например, 70% мадам, 5% CPU. Я остановил все несущественные сервисы, таким образом, использование очень ровно. Эти отключения электричества особенно не происходят во времена увеличенной памяти/CPU (во время ежедневных задач), они иногда происходят во времена очень низкого использования CPU (<2%), но в прошлом также произошел во время свопинга.

Эти отключения питания происходили и в соответствии с Ubuntu 12.04 LTS и в соответствии с Ubuntu 14.04 LTS - никакое изменение вообще (я обновил Ubuntu конкретно, чтобы видеть, помогло ли это этой проблеме).

Возможно войти в наш webhosts сайт и использовать их консоль администрирования для наблюдения сообщений об ошибках от в это время. По-видимому, эти сообщения от виртуализации Xen, основное сообщение идет как это:

BUG: soft lockp - CPU#0 stuck for 22s! [ksoftireqd/0:3] (repeats many times)
SysRq : Emergency Sync (Sometimes this is the only message in the console)

Другие, замеченные ранее под различными ситуациями с загрузкой, включают:

BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0] 

(повторяемый много раз) или:

INFO: rcu_sched detected stall on CPU 0 (t=15000 jiffies) 

(повторяемый много раз с получением t больше)

От поиска с помощью Google вокруг я попробовал различные параметры ядра, такие как nohz=off и acpi=off напрасно. Вся техническая поддержка сказала, то, что другие установки Ubuntu не переносят той же проблемы.

Кто-либо получил какие-либо идеи или опыт с этой проблемой?

5
задан 4 June 2014 в 03:24
2 ответа

Ну, я не смог найти решения этой проблемы, что бы я ни пытался. В конце концов, я заменил Ubuntu на Debian 7.0, и проблема исчезла, вместе с некоторой аномальной загрузкой процессора, которая не появилась в верхней части, но появилась в панели мониторинга VPS (эта загрузка процессора проявилась в постепенном увеличении за 2-3 дня до 10%, за которым последовало падение до 0%, в результате чего на графике загрузки процессора появился шаблон "sawtooth"). Я сделал , а не попытку переустановки Ubuntu (хотя я и пытался обновиться до 14.04), из-за этого я не могу сказать наверняка, что замена Ubuntu на Debian была решением. Тем не менее, Debian был настолько твёрдым, насколько можно было ожидать от его репутации, к сожалению, я могу сказать то же самое о репутации Ubuntu. Я люблю Ubuntu, и я абсолютно люблю Unity, но, похоже, Ubuntu действительно не является стабильным на таком широком спектре оборудования.

Я ответил на свой вопрос, потому что 1) я нашёл решение и 2) я не смог найти решение где-либо ещё (за исключением случая с CentOS, понижение CentOS 6 до CentOS 5), так что, может быть, это будет полезно, если, возможно, не приветствовать других, у кого есть эта проблема. Я знаю, что не был бы доволен решением: Замените Ubuntu на Debian! Но в конце концов, это то, что я сделал, чтобы исправить проблему. Кстати, я остановился на Debian, потому что не нашел никаких сообщений об этой проблеме для Debian, в то время как я нашел сообщения об этой проблеме для Ubuntu и CentOS.

.
4
ответ дан 3 December 2019 в 01:18

Надеюсь, это поможет любому, кто смотрит на эту проблему в будущем.

Мы столкнулись с этой проблемой в похожей среде:

  • Ubuntu 14.04 3.13.0 Kernel
  • QEMU KVM окружение

Мастер нашего кластера Splunk выдавал эти предупреждения в среднем каждые пять минут. Загрузка процессора обычно поднималась до 35%, а в предупреждениях перечислялись splunkd или python, как процесс, который, скорее всего, и вызвал блокировку.

После долгих волосинок и скрежетания зубов, в отчаянии мы изменили настройку дисковой шины в Virt-Manager с 'virtio' на 'SATA'.

Проблема ушла.

На данный момент мы все еще следим за системой, но с момента изменения (пока полчаса) предупреждений больше не поступало и загрузка процессора стабильна примерно на 2%.

Я знаю, что немного рановато раздавать шампанское и фейерверки, но мы надеемся на это.

4
ответ дан 3 December 2019 в 01:18

Теги

Похожие вопросы