У меня сейчас есть VPS с Linode. Моя служба мониторинга предупредила меня о том, что сайт, который я размещал, вышел из строя. Я использовал Lish, метод Linode для получения прямого внеполосного доступа к консоли через SSH-соединение, но без использования SSH, чтобы увидеть сообщения об ошибках. Вот что я увидел:
Я проверил свои журналы Munin, чтобы увидеть, был ли всплеск использования памяти, и действительно ли всплеск в подходящее время для графика подкачки:
Однако на графике памяти всплеска не было (хотя своп, похоже, растет слегка):
Я перезапустил сервер, и с тех пор он работает нормально. Я проверил доступ к Apache и журналы ошибок и ничего подозрительного не обнаружил. Последняя запись в системном журнале перед перезапуском сервера была ошибкой демона IMAP и, похоже, не связана:
Oct 28 18:30:35 hostname imapd: TIMEOUT, user=user@xxxxxxxxxxxxx.com, ip=[::ffff:XX.XX.XX.XX], headers=0, body=0, rcvd=195, sent=680, time=1803
# all of the startup logs below here
Oct 28 18:40:33 hostname kernel: imklog 5.8.1, log source = /proc/kmsg started.
Пытался проверить dmesg, но ничего подозрительного тоже не увидел. Последние несколько строк:
VFS: Mounted root (ext3 filesystem) readonly on device 202:0. devtmpfs: mounted Freeing unused kernel memory: 412k freed Write protecting the kernel text: 5704k Write protecting the kernel read-only data: 1384k NX-protecting the kernel data: 3512k init: Failed to spawn console-setup main process: unable to execute: No such file or directory udevd[1040]: starting version 173 Adding 524284k swap on /dev/xvdb. Priority:-1 extents:1 across:524284k SS init: udev-fallback-graphics main process (1979) terminated with status 1 init: plymouth main process (1002) killed by SEGV signal init: plymouth-splash main process (1983) terminated with status 2 EXT3-fs (xvda): using internal journal init: plymouth-log main process (2017) terminated with status 1 init: plymouth-upstart-bridge main process (2143) terminated with status 1 init: ssh main process (2042) terminated with status 255 init: failsafe main process (2018) killed by TERM signal init: apport pre-start process (2363) terminated with status 1 init: apport post-stop process (2371) terminated with status 1
Я пробовал погуглить сообщение об ошибке (kernel BUG at mm/swapfile.c:2527!
) и нашел несколько тем, связанных с Xen (Linode использует Xen):
Однако ни одна из найденных мной сведений не указывала на какое-либо решение. Я собираюсь обновить ядро до последних предложений Linode (с 2.6.39.1-linode34
к 3.0.4-linode38
).
Могу ли я еще что-нибудь сделать для диагностики этой проблемы сейчас или в будущем, если она повторится снова? Я что-то пропустил? У кого-нибудь есть идеи, что могло спровоцировать это?
Пожалуйста, дайте мне знать, если я могу предоставить какую-либо другую информацию. Благодаря тонну.
Проблема была связана с ошибкой в Xen (упомянутой в вопросе). Обновление ядра до последней версии (3.0.4-linode38
) решил проблемы (сервер неоднократно падал, пока я не изменил версию ядра). Похоже, что проблемы возникли не из-за нехватки памяти, а из-за неправильного управления памятью ядром (или какой-то ошибки в Xen).
Вы тянули графики Мунина до или после перезагрузки системы? Если после, то, скорее всего, часть после пустой секции ПОСЛЕ вы перезагружались, и не имеет значения. Я предполагаю, что это будет после, потому что ваше использование подкачки резко упало ...
В своем вопросе вы игнорируете пустой раздел ... Вы говорите, что «график не показывает увеличение использования памяти», но на самом деле они показывают отсутствие данных в то время, когда объем памяти, вероятно, увеличивался. munin - отличный инструмент, но он ужасен в таких случаях, потому что он сообщает информацию только каждые 5 минут, а если система занята, она может вообще ничего не сообщать.
Вы подсчитали количество экземпляров Apache, которые вы можете запустить? Под этим я подразумеваю "ps awwlx --sort = rss | grep apache" и посмотрите, сколько памяти использует каждый экземпляр Apache. Например:
root@theobromine:~# ps awwlx --sort=rss | grep apache
0 0 18497 18485 20 0 1788 528 - S+ pts/0 0:00 grep apache
5 33 18458 5384 20 0 28468 6700 - S ? 0:00 /usr/sbin/apache2 -k start
5 33 18470 5384 20 0 28468 6700 - S ? 0:00 /usr/sbin/apache2 -k start
5 33 18480 5384 20 0 28468 6700 - S ? 0:00 /usr/sbin/apache2 -k start
5 33 18481 5384 20 0 28468 6700 - S ? 0:00 /usr/sbin/apache2 -k start
5 33 18457 5384 20 0 28468 6708 - S ? 0:00 /usr/sbin/apache2 -k start
5 0 5384 1 20 0 28336 11796 - Ss ? 0:16 /usr/sbin/apache2 -k start
Мы смотрим на восьмую колонку. В этом случае для каждого экземпляра используется 6,7 МБ, что на самом деле довольно мало. Но теперь смотрю, сколько у меня памяти:
root@theobromine:~# free
total used free shared buffers cached
Mem: 775196 643848 131348 0 77964 268788
-/+ buffers/cache: 297096 478100
Swap: 1148636 3368 1145268
Итак, у меня 800 МБ ОЗУ ... Теперь я могу посчитать и сказать, что в лучшем случае я могу запустить 800 / 6,7 = 119 экземпляров Apache. Но это не оставляет места для других приложений, ОС, кеша и т. Д.
Но на самом деле у вас есть не более 478 МБ (второй столбец под заголовком «бесплатно») за вычетом количества запущенных в данный момент Apache (6,7 * 6 - у меня было только 6 экземпляров Apache, работающих выше), оставляя около 520 МБ ОЗУ (если вы оставите без кеш, конечно). Так что максимум, который я действительно могу запустить, больше похож на 77 экземпляров.
Так сколько я на самом деле бегаю?
root@theobromine:~# grep MaxClients /etc/apache2/apache2.conf
# MaxClients: maximum number of server processes allowed to start
MaxClients 150
# MaxClients: maximum number of simultaneous client connections
MaxClients 150
Ах, Apache не ограничивает меня меньшим объемом памяти, чем у меня. Итак, если к моему веб-серверу одновременно подключится более 77 клиентов, я, скорее всего, начну сбиваться.
Я довольно часто вижу это: «Мне нужно иметь возможность обрабатывать 500 одновременных веб-соединений». Но затем вы смотрите на их экземпляры Apache, и они используют 60 МБ (нередко большой размер), но затем они приходят в ужас, когда вы говорите, что им нужно обновить свой VPS до 32 ГБ ОЗУ. :-)