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