В настоящее время я являюсь администратором Moodle в своем университете, и одна из моих обязанностей заключается в том, чтобы сервер постоянно работал и работал. Иногда без видимой причины происходит сбой Apache и / или MySQL, вызывая полный хаос в университете.
В широком смысле, каковы «основные рекомендации», которым следует следовать при сбое сервера? Что мне делать в первую очередь, чтобы узнать, что случилось? Как мне узнать, сколько пользователей было подключено во время сбоя (или в любой момент времени)? Как узнать, сколько памяти или мощности мне нужно для удовлетворения текущих потребностей?
Есть много вопросов, связанных друг с другом, но это самые важные. Очевидно, я далеко не опытный сисадмин. Я немного разбираюсь в Linux, если это поможет.
Наши спецификации сервера:
РЕДАКТИРОВАТЬ: извините за отсутствие информации.
Я прочитал журналы Apache и MySQL без каких-либо значимых данных. Apache является наиболее информативным, говоря, КОГДА он разбился, но не по другой причине. Фактически, ошибка при сбое Apache на самом деле не является «ошибкой», это просто повторная инициализация записи в журнале - в худшем случае Apache выдает «SIGTERM» или «SIGKILL». Журналы MySQL ни о чем не говорят.
Обычно я стараюсь следить за происходящим, используя «верх». Когда случаются сбои, редко используется вся (или даже половина) системной памяти. В действительно ужасных ситуациях загрузка процессора достигла ... 80%?
Использование диска и памяти кажется нормальным (du и free не показывают проблем). Доступ по SSH обычно в порядке. Просто кажется, что MySQL или Apache случайно вылетает из строя, потому что, даже когда спрос не так высок, он все равно зависает.
Проблема может быть сведена к "Какие журналы проверять?" "Как проверить количество подключений?"
Обычно вы хотите начать с просмотра журналов системы и приложений, которые могут что-то раскрыть, а могут и не раскрыть. Если у вас есть сар запущенных инструментов, вы захотите посмотреть статистику вашей системы, ведущую к сбою.
Конечно, всегда полезно проверять очевидные вещи, такие как заполнение диска, перебои с питанием, недавний вход в систему (возможно, кто-то другой набрал «перезагрузка»).
В зависимости от сбоя вы можете посмотреть на консоль, чтобы увидеть, есть ли на дисплее какая-либо информация о дампе.
Если вы не можете найти ничего очевидного в журналах, вашим следующим шагом может быть угадать, в чем, по вашему мнению, проблема, и создать несколько сценариев для мониторинга этого аспекта системы, чтобы вы могли получить более полезную информацию в будущем. Если вы думаете, что количество подключений может быть проблемой, вы можете периодически собирать выходные данные netstat или что-то еще.
В таких ситуациях очень полезны файлы дампа ядра. Доступны ли дампы ядра из времен сбоя? http://linux.die.net/man/5/core