Приветствую вас, гуру превосходного сервера!
Я использую сервер Ubuntu, на котором размещены служба Apache Tomcat и база данных MySQL. Нагрузка на сервер всегда близка к нулю, даже в самые загруженные часы недели. Несмотря на это, я сталкиваюсь с случайными зависаниями 1-2 раза в неделю, когда весь сервер перестает отвечать.
Интересным эффектом этой блокировки является то, что все cronjobs, похоже, выполняются позже запланированного, по крайней мере, так показывают временные метки в различных системных журналах. Таким образом, мне кажется, что действительно зависает весь сервер, а не только пользовательское программное обеспечение, работающее как часть службы tomcat. Зависание обычно длится около 3-5 минут, а затем все возвращается в норму.
Hardware:
Model: Dell PowerEdge R720, 16 cores, 16 GB ram
HDD-configuration: Raid-1 (mirror)
Main services:
apache tomcat, mysql, ssh/sftp
#uname -a
Linux es2 2.6.24-24-server #1 SMP Tue Jul 7 19:39:36 UTC 2009 x86_64 GNU/Linux
Запустив sysstat, я вижу огромные пики как в средней нагрузке, так и в ожидании дисковых блоков, которые по времени точно соответствуют тому, когда клиенты сообщали о проблемах с бэкэнд-системой. Ниже приведен график использования диска от sar с очень очевидным пиком около 12.30.
Мои искренние извинения за размещение этого на внешнем сервере, но моя репутация слишком низкая, чтобы включать файлы здесь напрямую. Также пришлось собрать их вместе, так как я могу разместить только одну ссылку :S
Участки Sar:http://213.115.101.5/abba/tmpdata/sardata_es.jpg
График 1: Блокировка ожидания, обратите внимание, как util% увеличивается до 100% примерно при 12,58
График 2: Блок-передача, здесь ничего необычного.
График 3: Средняя нагрузка, пики вместе с графиком 1
График 4: Загрузка ЦП все еще близка к 0%.
График 5: Память, здесь ничего необычного.
Есть ли у кого-нибудь идеи, что может вызывать такой эффект в системе? Как я уже объяснял ранее, единственное программное обеспечение, работающее на сервере, — это сервер tomcat с интерфейсом SOAP, чтобы пользователи могли подключаться к базе данных. Удаленные приложения также подключаются к серверу через SSH, чтобы извлекать и загружать на него файлы. В часы пик я предполагаю, что у нас около 50 одновременных подключений SSH/SFTP и не более 1-200 подключений по http (soap/tomcat).
Погуглив, я нашел обсуждения о файловых дескрипторах и дескрипторах inode, но я думаю, что это нормально для ядер 2.6.x. Кто-нибудь не согласен?
cat /proc/sys/fs/file-nr
1152 0 1588671
cat /proc/sys/fs/inode-state
11392 236 0 0 0 0 0
В то же время "sar -v" показывает эти значения для времени зависания выше, но inode-nr здесь ВСЕГДА очень высок по сравнению с вышеприведенным.
12:40:01 dentunusd file-nr inode-nr pty-nr
12:40:01 40542 1024 15316 0
12:45:01 40568 1152 15349 0
12:50:01 40587 768 15365 0
12:55:01 40631 1024 15422 0
13:01:02 40648 896 15482 0
13:05:01 40595 768 15430 0
13:10:01 40637 1024 15465 0
Я видел это на двух независимых серверах, работающих под управлением одинаковой конфигурации оборудования, ОС, программного обеспечения, конфигурации RAID и т. д. Поэтому я хочу верить, что это больше зависит от программного обеспечения/конфигурации, чем от оборудования.
Большое спасибо за уделенное время
/Эббе
решение1
Проблемы были связаны с несовместимостью Ubuntu 8.04 LTS (Hardy) и RAID-контроллера Dell PERC 6/i, о чем сообщается в этом сообщении об ошибке:https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607167 Обновление до Ubuntu 10.04 LTS Lucid (ядро 2.6.32) решает проблему.
На случай, если кто-то еще столкнется с такими же проблемами.
решение2
Может быть, вы запускаете какой-то тяжелый запрос, который делает полное сканирование таблицы. Вы проверили свой журнал медленных запросов.
Если это так, просто добавьте соответствующие индексы.
PS: Извините, если вы это уже сделали.