За последние несколько дней Apache вышел из-под контроля и дважды приводил к краху MySQL. Все началось, когда я перенес сайт WordPress, на котором также есть форум phpBB.
Я не очень опытен в администрировании сервера, поэтому мне было очень сложно определить причину проблемы. Когда я заметил, что MySQL не работает, я запустил TOP и увидел скачок загрузки системы до 98.00. На сервере запущено 10 V-HOSTS, каждый из которых получает значительный объем трафика, поэтому я, очевидно, видел множество запущенных процессов apache-2.
Высокая загрузка сервера продолжалась в течение 10 минут, а затем вернулась в нормальное состояние. Я не видел всплеска сетевого трафика в этот момент.
К сожалению, регистрация ошибок MySQL была отключена (теперь она включена повторно), поэтому никаких подсказок нет. Но я уверен, что это потому, что Apache потреблял все ресурсы, поэтому идентификатор процесса MySQL был уничтожен.
Мои вопросы:
В следующий раз, когда это произойдет, - как я могу определить, что вызывает скачок загрузки системы? Может ли это быть PHP-скрипт, который сошел с ума? Это может быть атака DDOS?
Есть ли способ автоматического перезапуска MySQL при сбое?
Я сейчас установил htop. Может ли это быть более полезным, чем top?
Вот моя статистика сервера:
m1.xlarge (8 ECUs, 4 vCPUs, 15 GiB memory, 4 x 420 GiB Storage Capacity)
Ubuntu Server 12.04.3 LTS
источник
dmesgпоможет?Ответы:
MySQL может все еще ничего не регистрировать, потому что, вероятно, происходит то, что он бесцеремонно уничтожается системой из-за давления системной памяти от детей apache. След должен быть в / var / log / syslog.
MySQL должен попытаться перезапустить себя в случае сбоя или принудительного завершения, но, если недостаточно памяти, он не может этого сделать ... и этот второй сбой не рассматривается mysqld_safe как "сбой", а скорее как "отказ от начать ", поэтому он не будет продолжать пытаться. Неудачная попытка перезапуска часто неверно истолковывается администраторами как «сбой», поскольку природа исходного сбоя скрывается за легко пропускаемым сообщением в журнале ошибок MySQL:
См. InnoDB Crash Post Mortem для обстоятельств, которые, как я подозреваю, похожи на ваши.
Казалось бы, простой ответ на вопрос «почему» заключается в том, что между Apache и MySQL, имеющейся у вас нагрузкой и вашими текущими конфигурациями у вас недостаточно памяти на машине, и есть некоторая переломная точка, связанная с нагрузкой трафика, которая выводит это условие ,
Apache обслуживает каждый параллельный запрос браузера от дочернего процесса, поэтому с увеличением числа одновременных подключений количество дочерних объектов будет увеличиваться. Сначала вам нужно будет ограничить это значение в конфигурации Apache, чтобы вы могли понять, что на самом деле вызывает увеличение числа одновременных подключений ... Это просто тяжелый, но допустимый всплеск трафика? Какой-то отказ в обслуживании? Запросы к БД, которые задерживают запросы, потому что они выполняются слишком долго? Что-то нуждается в оптимизации?
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients
Ограничение одновременных процессов Apache должно помочь предотвратить это, но, для ясности, наивно думать, что это полное решение, поэтому я не хочу это подразумевать. Как только процессы ограничены разумным или хотя бы более безопасным уровнем, вы можете приступить к определению того, что на самом деле происходит. (В Apache есть и другие средства контроля за ограничениями, но это не моя область знаний.)
«Лучшая практика» - это, конечно, запускать базу данных на другом оборудовании, чтобы приложение не могло ее уничтожить. Хотя на первый взгляд кажется более эффективным «максимизировать использование» одной машины, разделяя ее, это ложная экономия. Большая часть памяти, используемой MySQL, в типичной рабочей нагрузке выделяется во время запуска и удерживается до тех пор, пока работает MySQL Server. Требования к процессору, вероятно, будут разделять пиковое время для MySQL и Apache, так как они в конечном итоге обслуживают одинаковую нагрузку. На самом деле, вам может быть лучше использовать две машины m1.large вместо одной m1.xlarge, и стоимость будет такой же, поскольку меньшая - ровно половина стоимости большей ... даже если вы уже заплатили заранее для дополнительной скидки это изменение может быть выполнено .
источник
У вас есть несколько пунктов, чтобы проверить:
-Проверьте / var / log / messages: oomkiller может убить процесс mysql, если больше нет памяти для использования. Проверьте оперативную память с помощью свободного -lm (без кеша)
-Если вы используете apache с prefork mpm: проверьте количество процессов. Если в Apache используется большое количество процессов (во время большой рабочей нагрузки) со ссылкой на mysql, задержка и используемая память могут быстро возрасти.
-Проверьте количество потоков, запущенных mysql, с показом глобального статуса : threads_cached, threads_created и threads_running важны для проверки (threads_created должно быть около 0).
-Проверьте баран, используемый Mysql.
источник
Вы также можете изучить реализацию процессоров и резервирование ресурсов для mysql. Это наиболее близко к запуску этих сервисов на другом оборудовании, но все же дает вам преимущества поддержки одного сервера.
источник