Итак, у нас работает Ubuntu 10.04 - все 64-битные. Ядро 2.6.36 и 2.6.38-15 имеют одинаковые проблемы.
Проблема в том, что случайные серверы VPS зависают. У нас около 30 экземпляров с этим конкретным хостом. Он зависает, и в журналах ничего нет - ни в dmesg, ни в kernel.log, ни в syslog, ни где-либо еще. Ведение журнала настроено правильно.
Однако в консоли есть несколько ошибок «задача зависла на 120 секунд» во время этого сбоя. Система явно не может писать во время этого сбоя. У нас есть два типа серверов: серверы веб-приложений Java и серверы MySQL.
Оба типа имеют ошибки "" задача flush-2 ** / java / kjournald заблокирована более 120 секунд. "Даже на сервере без установленного Java-приложения mysqld блокируется более чем на 120 секунд". Каждые несколько дней.
Использование памяти нормальное. Свап почти не используется. Но случайным образом каждые несколько дней, когда происходит скачок нагрузки, между 8-10 средними нагрузками - случайный экземпляр сервера / vps просто зависает с ошибкой. Проведены нагрузочные тесты до 100 средн. (800% на 8 ядрах), проведены стресс-тесты ввода-вывода. Время ожидания ввода-вывода нормальное во время сбоя. Кажется, мы не можем воспроизвести эту проблему с помощью стресс-тестов.
Система MySQL имеет 8 ядер (2 процессора) - серверы приложений Java имеют 2-ядерную систему - все Intel Xeon. Очевидно, они также находятся на разных родительских серверах Xen. Интернет-провайдер сообщает, что известных проблем с оборудованием нет, а с другими «гостями» все в порядке. Они тоже в тупике. Могу ли я что-нибудь сделать, чтобы выяснить, в чем проблема? Нет дампа ядра или чего-либо, что система может записать, когда происходит сбой.
Я попытался изменить планировщик ввода-вывода с некоторым прогрессом. По умолчанию на некоторых серверах были CFQ и Deadline, я изменил планировщик на noop с некоторым успехом, но серверы все равно падают. fstab - это "/ dev / xvda3 / ext3 errors = remount-ro 0 1"
На всех серверах установлены патчи, брандмауэры, и в журналах нет ничего странного. Fsck было сделано. Xen версии 3.4 согласно dmesg. Мы используем XYMON для мониторинга, и незадолго до отказа TOP память и т. Д. Кажутся нормальными.
Еще одна странная странность, которую я обнаружил, заключается в том, что установка часов совпадает с загрузкой системы.
На графике средняя загрузка процессора соответствует более высокому смещению тактовой частоты - по этой причине ntpudate необходимо запускать каждые 5 минут. это нормально для нагрузки? или это может быть проблема с оборудованием?
Могу ли я выяснить причину этого?
тиа
Есть ли у вас какие-либо настройки мониторинга (Zenoss, Icinga, Nagios)? Один из них предоставит вам много информации, особенно в зависимости от того, как они настроены. Я не удивлюсь, если какой-то процесс имеет утечку памяти или убегает. Вы можете настроить быстрый и грязный мониторинг, который может дать вам некоторую информацию:
# top -d 5 > /var/log/top.out
Наряду с сообщениями ядра, которые вы видели в консоли, он также отображал ошибки в следующих строках:
BUG: soft lockup - CPU#2 stuck for XXXXXXXXXs! [process:XXXX]
Если да, посмотрите: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556030
Последний комментарий позволяет включить более подробное ведение журнала, чтобы вы могли увидеть, что его вызывает. Однако для этого потребуется немного изменить и перекомпилировать ядро.