☰

Средний трафик приводит к необходимости жесткой перезагрузки сервера WordPress

tag-icon • tag-icon apache-2.4 wordpress centos7 mariadb rackspace
Средний трафик приводит к необходимости жесткой перезагрузки сервера WordPress

У нас возникли проблемы с нашим сервером WordPress в Rackspace, который падает при среднем трафике после отправки электронного письма.

Характеристики сервера:

CPU            2 vCPUs
RAM            2 GB
System Disk   80 GB
Network      240 Mb / s
Disk I/O    Good

Бег:

Centos       7.0
Wordpress  4.3.1
Httpd      2.4.6
PHP       5.4.11
MariaDB   5.5.41

Насколько я могу судить, установка довольно стандартная, и база данных довольно стандартная, индексированная и довольно маленькая. Мы также кэшируем объекты WordPress.

Согласно New Relic; при нормальном трафике сайт проводит около 80% времени в PHP, 15% времени во внешнем вебе и лишь небольшой процент в базе данных. Среднее стандартное время приложения страницы составляет около 800 мс, что мне кажется медленным.

Запуск нагрузочного теста с 250 соединениями за 1 минуту приводит к тому, что соединения становятся все более длительными, а затем начинают выходить из строя примерно через 30 минут, и сервер перестает отвечать (даже когда трафик снова падает). Для того, чтобы снова стать активным, требуется жесткая перезагрузка.

Я не могу подключиться с помощью Putty, а домашняя страница колеблется между тайм-аутом и ужасной ошибкой «Ошибка установления соединения с базой данных».

Используя агент мониторинга пространства стойки в последнем тесте, мы видим, что ЦП достигает 100% перед самым выходом из строя, используемая память достигает пика около 1,6 ГБ, а свободная падает до 100 МБ. Похоже, что также используется около 2 ГБ памяти подкачки (всего 4 ГБ). Стандартное использование составляет около 15% ЦП, 800 МБ памяти и 400 МБ подкачки.

В нашей конфигурации Apache не заданы следующие параметры (нет файлов в /etcdo); Timeout, KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout; поэтому я предполагаю, что используются значения по умолчанию.

Я посмотрел настройки mariadb:

innodb_buffer_pool_size = 1400M
max_user_connections = 0

Но, похоже, причина не в этом.

Я также включил performance_schema, но я не совсем понимаю, что именно ищу. Я даже не уверен, что проблема в БД.

Мне хочется обновить экземпляр, но я бы предпочел иметь более четкое представление о том, где находится узкое место и что заставляет сервер умирать, а не просто замедлять его работу.

Есть идеи, с чего начать? Кажется, есть много возможных настроек и много информации.

решение1

Тщательный мониторинг во время любого события имеет решающее значение. Как мы видим, правда вышла наружу:

Используя агент мониторинга пространства стойки в последнем тесте, мы видим, что ЦП достигает 100% перед самым выходом из строя, используемая память достигает пика около 1,6 ГБ, а свободная падает до 100 МБ. Похоже, что также используется около 2 ГБ памяти подкачки (всего 4 ГБ). Стандартное использование составляет около 15% ЦП, 800 МБ памяти и 400 МБ подкачки.

PHP, как известно, довольно требователен к ресурсам процессора. Вы использовали весь доступный процессор и почти всю доступную оперативную память.

Сначала вам следует предпринять шаги для решения этой проблемы, например, кэширование опкода (например, Zend OPcache) и кэширование файлов (например, плагин W3 Total Cache WordPress). Если это не поможетдостаточно, то пришло время обновить экземпляр.

решение2

Вероятно, вы просто запускаете слишком много процессов одновременно, исчерпываете память и перегружаете swap. Возможно, что-то еще блокирует, но сначала разберитесь с этим, а затем посмотрите, где вы находитесь.

Вы не сказали нам, используете ли вы mod_php или что-то вроде php-fpm. Последний лучше справляется с нагрузкой, но в любом случае убедитесь, что вы не запускаете больше процессов php, чем у вас есть памяти. Вы, вероятно, не получите никакого выигрыша в производительности от запуска более 5 или 10 процессов, но запуск mod_php по умолчанию в частности будет запускать гораздо больше, чем у вас есть памяти. Кроме того, перезапускайте процессы каждые 30 или около того запросов. Если вы выделяете 1 ГБ вашей базе данных и ОС, то ваш другой ГБ, вероятно, не справится с 10 процессами WordPress. Посмотрите, сколько памяти они занимают, и посчитайте, с небольшим зазором. Вам не следует использовать подкачку в обычном порядке вещей.

Посмотрите на настройки keep-alive. С Apache вам, вероятно, лучше всего отключить его или установить на 1 секунду. Nginx обрабатывает keep-alive гораздо лучше. Фактически, это единственная действительно важная причина, по которой nginx, скорее всего, будет работать лучше с php-приложением, таким как WordPress (хотя это достигается ценой менее приятной конфигурации). Это, скорее всего, не является фактором при вашем тестировании, но важно для реальных браузеров.

100% CPU меня удивляет. Используйте top, чтобы увидеть, что его использует. Помните также, что 100% часто означает 100% одного ядра. Вы можете просто увидеть одно задание cron, которое в WordPress обычно не является "cron" как таковым, а скорее заданиями, которые запускаются как дополнительные при обработке веб-запросов. Отсутствие кэширования opcode также может быть причиной высокой загрузки процессора.

Связанный контент