У нас есть VPS под управлением Ubuntu на Xen. Проблема в том, что примерно раз в день в течение примерно 20-50 минут в случайное время сервер полностью перестает отвечать на запросы внешнего мира. По истечении этого периода он снова становится отзывчивым, как ни в чем не бывало, он не теряет время безотказной работы, он не перезагружается. Он просто снова начинает отвечать, как если бы он был в приостановленном состоянии.
Эти сбои происходят в условиях неисключительной памяти и ЦП, например 70% памяти, 5% ЦП. Я остановил все второстепенные службы, поэтому использование очень равномерное. Эти сбои особенно не происходят во время увеличения памяти / ЦП (во время ежедневных задач), они иногда возникают во время очень низкого использования ЦП (<2%), но в прошлом также происходили во время подкачки.
Эти отключения происходят как в Ubuntu 12.04 LTS, так и в Ubuntu 14.04 LTS - никаких изменений (я обновил Ubuntu специально, чтобы посмотреть, помогло ли это решить эту проблему).
В это время можно войти на сайт наших веб-хостов и использовать их административную консоль, чтобы просматривать сообщения об ошибках. Предположительно, это сообщения от виртуализации 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 не страдают такой же проблемой.
У кого-нибудь есть идеи или опыт решения этой проблемы?
Надеюсь, это поможет любому, кто будет заниматься этой проблемой в будущем.
Мы столкнулись с этой проблемой в аналогичной среде:
Наш мастер кластера Splunk выдавал эти предупреждения в среднем каждые пять минут. Загрузка ЦП обычно возрастает до 35%, а в предупреждениях будут указаны splunkd или python как процесс, который, скорее всего, вызвал блокировку.
После долгого выдергивания волос и скрежета зубов, в отчаянии мы изменили настройку дисковой шины в Virt-Manager с virtio на SATA.
Проблема ушла.
На данный момент мы все еще отслеживаем систему, но она больше не выдавала предупреждений с момента изменения (уже полчаса), и загрузка процессора стабильна на уровне около 2%.
Я знаю, что еще рано начинать шампанское и фейерверк, но мы надеемся.
Что ж, я не мог найти никакого решения этой проблемы, что бы я ни пробовал. В конце концов, я заменил Ubuntu на Debian 7.0, и проблема исчезла вместе с некоторым аномальным использованием ЦП, которое не отображалось в верхней части, но отображалось на панели мониторинга VPS (это использование ЦП проявлялось как постепенное увеличение по сравнению с 2- 3 дня до 10% с последующим снижением до 0%, что приводит к появлению «пилообразного» рисунка на графике использования ЦП). я сделал не попробуйте переустановить Ubuntu (хотя я пробовал обновиться до 14.04), из-за этого я не могу с уверенностью сказать, что замена Ubuntu на Debian была решением. Тем не менее, Debian оказался столь же надежным, как и следовало ожидать от его репутации, к сожалению, я могу сказать то же самое и о Ubuntu, отвечающем его репутации. Я люблю Ubuntu, и мне очень нравится Unity, но похоже, что Ubuntu действительно нестабильна на таком широком спектре оборудования.
Я ответил на свой вопрос, потому что 1) я нашел решение и 2) я не смог найти решение где-либо еще (кроме CentOS, понижения версии CentOS 6 до CentOS 5), так что это может быть полезно, если, возможно, не приветствуется другим с этой проблемой. Я знаю, что мне бы не понравилось решение: заменить Ubuntu на Debian! Но в конце концов это то, что я сделал, чтобы исправить проблему. Между прочим, я остановился на Debian, потому что я не нашел отчетов об этой проблеме для Debian, в то время как я нашел отчеты об этой проблеме для Ubuntu и CentOS.