Что может привести к тому, что ВСЕ службы на сервере отключатся, но все равно будут отвечать на пинг? и как выяснить
Со мной уже дважды в течение нескольких дней случалось, что мой сервер полностью отключается, что означает http, ssh, ftp, dns, smtp, в основном ВСЕ службы перестают отвечать, как если бы сервер был выключен, за исключением того, что он все еще отвечает на ping , что меня больше всего волнует.
У меня есть несколько скриптов php, которые вызывают огромную нагрузку (ЦП и память) на сервере короткими всплесками, используемыми небольшой группой пользователей, но обычно сервер "выживает" отлично после этих всплесков, и когда он выходит из строя, он никогда не совпадают с такими пиками использования (я не говорю, что это не может быть связано, но это не происходит сразу после них).
Я не прошу вас волшебным образом указать мне основную причину этих сбоев, мой вопрос: существует ли один процесс, смерть которого может вызвать одновременное отключение всех этих служб? Самое смешное, что все сетевые сервисы не работают, кроме ping. Если у сервера 100% ЦП было израсходовано каким-либо процессом, он тоже не ответил бы на пинг. Если apache выйдет из строя из-за (например) сломанного скрипта php, это повлияет только на http, а не на ssh и dns ....
Моя ОС - Cent OS 5.6
Самое главное, какие системные журналы мне следует посмотреть после жесткой перезагрузки сервера? / var / log / messages ничего подозрительного не обнаруживает.
(tl; dr все еще отвечать на пинг - это ожидаемое поведение, проверьте использование памяти)
Эхо-запросы ICMP (т. Е. Ping) обрабатываются встроенным в ядро сетевым стеком без какой-либо другой зависимости.
Ядро известно как «резидентное в памяти», что означает, что оно всегда будет храниться в ОЗУ и не может быть заменено на диск, как это делает обычное приложение.
Это означает, что в ситуациях, когда у вас заканчивается физическая память, приложения выгружаются на диск, но ядро остается там, где оно есть. Когда и физическая память, и память подкачки заполнены (а система больше не может управлять вашими программами), машина выйдет из строя. Однако поскольку а) ядро все еще находится в памяти и б) он может отвечать на запросы ping без какой-либо помощи, система будет продолжать отвечать на запросы ping, несмотря на то, что все мертвы.
Что касается вашей проблемы, я бы сильно подозревал проблемы с памятью. Установите «sysstat» и используйте команду «sar», чтобы просмотреть журнал загрузки памяти / процессора / загрузки / io и т. Д. Я ожидал, что во время сбоя вы увидите как 100% физический ресурс, так и использование подкачки.
Я бы также рассмотрел возможность посмотреть на dmesg или / var / log / сообщения для любого признака вызова OOM-убийцы (убийцы нехватки памяти). Это аварийная система ядра, которая начнет убивать процессы в случае исчерпания памяти. Его эффективность во многом зависит от того, какие процессы убиваются. Одиночный процесс, занимающий память, будет эффективно уничтожен, а память освобождена, однако веб-сайт на основе Apache вызовет процессы замены, как только дочерний процесс будет уничтожен.
Обычно это проблема ввода-вывода или дисковой подсистемы. Часто это сопровождается чрезвычайно высокой средней загрузкой системы. Например, система, показанная на графике ниже, перестала отвечать (но была доступна для проверки связи), когда сценарий работал неправильно, блокировал кучу файлов и нагрузка возрастала до 36 ... в системе с 4 процессорами.
Службы, работающие в ОЗУ и не требующие доступа к диску, продолжают работать ... Таким образом, сетевой стек (ping) активен, но другие службы останавливаются, когда требуется доступ к диску ... SSH, когда указывается ключ или требуется поиск пароля. SMTP имеет тенденцию отключаться, когда средняя загрузка достигает 30 или около того ...
Когда система находится в этом состоянии, попробуйте удаленный nmap против IP-адреса сервера, чтобы узнать, что случилось.
Ваш журнал, вероятно, не работает, если это проблема с диском или хранилищем ...
Можете описать настройку оборудования? Это виртуальная машина? Какая схема хранения?
Вы хотите не только вести журнал, но и посмотреть, можете ли вы построить график производительности системы и понять, когда это происходит. Посмотрите, коррелирует ли это с конкретным видом деятельности.