У нас возникли проблемы с падением нашего сервера Wordpress в стойке со средним трафиком после отправки электронного письма.
Характеристики сервера:
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, и сервер перестает отвечать (даже когда трафик снова падает). Чтобы снова стать активным, требуется жесткая перезагрузка.
Я не могу подключиться с помощью шпатлевки, и домашняя страница колеблется между тайм-аутом и возвратом страшной «Ошибка установления соединения с базой данных».
Используя агент мониторинга стоечного пространства в самом последнем тесте, выяснилось, что процессор загружен на 100% незадолго до смерти, а используемая память достигает максимума около 1,6 ГБ со свободным сбросом примерно до 100 МБ. Похоже, что также используется около 2 ГБ памяти подкачки (всего 4 ГБ). Стандартное использование составляет около 15% ЦП, 800 МБ памяти и 400 МБ подкачки.
Наша конфигурация Apache не устанавливает ничего из следующего (нет файлов в /etc делать); Тайм-аут, KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout; поэтому я предполагаю, что он использует значения по умолчанию.
Я посмотрел настройки mariadb:
innodb_buffer_pool_size = 1400M
max_user_connections = 0
Что, кажется, не является причиной.
Я также включил performance_schema, но я действительно не знаю, что ищу. Я даже не уверен, что проблема в БД.
У меня возникает соблазн обновить экземпляр, но я бы предпочел иметь более четкое представление о том, где находится узкое место и почему сервер умирает, а не просто замедляется.
Есть идеи, с чего начать? Кажется, есть много возможных настроек и много информации.
Вероятно, вы просто запускаете слишком много процессов одновременно, нехватка памяти и сбой подкачки. Может быть, что-то еще блокируется, но сначала разберитесь с этим, а затем посмотрите, где вы находитесь.
Вы не сказали нам, используете ли вы mod_php или что-то вроде php-fpm. Последний лучше справляется с нагрузкой, но в любом случае убедитесь, что вы не запускаете больше php-процессов, чем у вас есть память. Вы, вероятно, не получите никакого выигрыша в производительности от запуска более 5 или 10 процессов, но запуск mod_php по умолчанию, в частности, будет работать намного больше, чем у вас есть память. Кроме того, повторно обрабатывайте каждые 30 запросов. Если вы дадите 1 ГБ своей базе данных и ОС, то ваш другой ГБ, вероятно, не будет обрабатывать 10 процессов WordPress. Посмотри сколько памяти берут и проработай, с небольшим просветом. Вы не должны использовать своп в обычном порядке.
Посмотрите на свои настройки keep-alive. С Apache вам, вероятно, лучше либо выключить его, либо установить на 1 секунду. Nginx намного лучше справляется с сохранением активности. Фактически, это единственная действительно важная причина, по которой nginx, вероятно, будет лучше работать с php-приложением, таким как WordPress (хотя это происходит за счет менее приятной конфигурации). Скорее всего, это не фактор вашего тестирования, но важно для реальных браузеров.
100% CPU меня удивляет. Используйте верхнюю часть, чтобы увидеть, что им используется. Помните также, что 100% часто означает 100% одного ядра. Вы можете просто увидеть, как срабатывает одно задание cron, которое в WordPress обычно не является "cron" как таковым, а скорее задания запускаются как дополнительные при обработке веб-запросов. Отсутствие кэширования кода операции также может вызывать высокую загрузку процессора.
Тщательный мониторинг во время любого события имеет решающее значение. Как видим, правда вышла наружу:
Используя агент мониторинга стоечного пространства в самом последнем тесте, выяснилось, что ЦП загружен на 100% непосредственно перед смертью, а используемая память достигает пика около 1,6 ГБ со свободным сбросом примерно до 100 МБ. Похоже, что также используется около 2 ГБ памяти подкачки (всего 4 ГБ). Стандартное использование составляет около 15% ЦП, 800 МБ памяти и 400 МБ подкачки.
Известно, что PHP довольно интенсивно использует процессор. Вы использовали весь доступный процессор и почти всю доступную оперативную память.
Сначала вы должны предпринять шаги для решения этой проблемы, такие как кеширование кода операции (например, Zend OPcache) и кеширование файлов (например, плагин W3 Total Cache WordPress). Если это не поможет достаточно, то пора обновить экземпляр.