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
решение1
MySQL может по-прежнему ничего не регистрировать, поскольку, скорее всего, он бесцеремонно уничтожается системой из-за давления на системную память со стороны потомков apache. След этого должен быть в /var/log/syslog.
MySQL должен попытаться перезапустить себя в случае сбоя или принудительного завершения, но если не будет достаточно памяти, он не сможет этого сделать... и эта вторая ошибка не будет воспринята mysqld_safe как "сбой", а скорее как "отказ от запуска", поэтому он не будет продолжать попытки. Неудачная попытка перезапуска часто неверно интерпретируется администраторами как "сбой", поскольку характер исходной ошибки скрыт за легко просматриваемым сообщением в журнале ошибок MySQL:
mysqld_safe Number of processes running now: 0
Видеть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, и стоимость будет такой же, поскольку меньшая стоит ровно половину большей... даже если вы уже заплатили заранее за дополнительную скидку,это изменение может быть достигнуто.
решение2
Вам нужно проверить несколько моментов:
-Проверьте /var/log/messages : oomkiller может завершить процесс mysql, если больше нет памяти для использования. Проверьте оперативную память с помощью free -lm (без кэша)
-Если вы используете Apache с prefork mpm: проверьте количество процессов. Если Apache объединяет важное количество процессов (при большой нагрузке) со ссылкой на MySQL, задержка и используемая память могут быстро вырасти.
-Проверьте количество потоков, запущенных MySQL, с помощьюпоказать глобальный статус: важно проверить threads_cached, threads_created и threads_running (threads_created должен быть близок к 0).
-Проверьте объем оперативной памяти, используемый Mysql.
решение3
Вы также можете рассмотреть возможность внедренияпроцессорыи резервирование ресурсов для mysql. Это наиболее близко к запуску этих служб на разном оборудовании, но при этом дает вам преимущества обслуживания одного сервера.