Средний трафик заставляет сервер Wordpress требовать "жесткой" перезагрузки
Мы испытываем затруднения из-за нашего rackspace сервера 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.
Согласно Новому Пережитку; во время обычного трафика сайт тратит приблизительно 80% времени в PHP, 15% времени во внешней сети и только небольшой процент в базе данных. Среднее стандартное время приложения страницы составляет приблизительно 800 мс, который действительно кажется медленным мне.
Выполнение нагрузочного теста 250 соединений за 1 минуту заставляет соединения брать прогрессивно дольше и затем начинать синхронизацию приблизительно после 30 и сервера для становления безразличным (даже когда трафик отмирает вниз). Это требует, чтобы "жесткая" перезагрузка стала активной снова.
Я не могу соединить шпаклевку использования, и домашняя страница колеблется между таймаутом и возвратом страшной 'Ошибки при Установлении Соединения с базой данных'.
Используя rackspace контролирующий агент на новом тесте кажется, что ЦП является maxing в 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, но я действительно не знаю то, что я ищу. Я даже не уверен, что DB является проблемой.
Я испытываю желание обновить экземпляр, но у меня было бы более четкое представление того, где узкое место и что заставляет сервер переставать работать, а не просто замедляться.
Какие-либо идеи о том, где запустить? Кажется, существует много возможных тонких настроек там и большая информация.
Тщательный мониторинг во время любого события имеет решающее значение. Как мы видим, правда вышла наружу:
Используя агент мониторинга стоечного пространства в самом последнем тесте, выяснилось, что ЦП работает до 100% непосредственно перед смертью, а используемая память достигает пика примерно на 1.6 ГБ при бесплатном сбросе примерно до 100 МБ. Похоже, что также используется около 2 ГБ памяти подкачки (всего 4 ГБ). Стандартное использование составляет около 15% ЦП, 800 МБ памяти и 400 МБ подкачки.
PHP, как известно, довольно интенсивно использует процессор. Вы использовали весь доступный процессор и почти всю доступную оперативную память.
Сначала вы должны предпринять шаги для решения этой проблемы, такие как кэширование кода операции (например, Zend OPcache) и кеширование файлов (например, плагин W3 Total Cache WordPress). . Если это не помогает достаточно , то пора обновить экземпляр.
Вероятно, вы просто запускаете слишком много процессов одновременно, нехватка памяти и сбой подкачки. Возможно, что-то еще блокируется, но сначала разберитесь с этим, а затем посмотрите, где вы находитесь.
Вы не сказали нам, используете ли вы mod_php или что-то вроде php-fpm. Последний лучше справляется с нагрузкой, но в любом случае убедитесь, что вы не запускаете больше php-процессов, чем у вас есть память. Вы, вероятно, не получите никакого выигрыша в производительности от запуска более 5 или 10 процессов, но, в частности, запуск mod_php по умолчанию будет работать намного больше, чем у вас есть память. Кроме того, повторно обрабатывайте каждые 30 запросов. Если вы дадите 1 ГБ своей базе данных и ОС, то ваш другой ГБ, вероятно, не будет обрабатывать 10 процессов WordPress. Посмотри сколько памяти берут и проработай, с небольшим просветом. Вы не должны использовать своп в обычном порядке.
Посмотрите на свои настройки проверки активности. С Apache вам, вероятно, лучше либо выключить его, либо установить на 1 секунду. Nginx намного лучше справляется с сохранением активности. Фактически, это единственная действительно важная причина, по которой nginx, вероятно, будет лучше работать с PHP-приложением, таким как WordPress (хотя это происходит за счет менее приятной конфигурации). Скорее всего, это не фактор вашего тестирования, но он важен для реальных браузеров.
100% CPU меня удивляет. Используйте верх, чтобы увидеть, что его использует. Помните также, что 100% часто означает 100% одного ядра. Возможно, вы просто видите, как срабатывает одно задание cron, которое в WordPress обычно не является «cron» как таковое, а скорее задания запускаются как дополнительные при обработке веб-запросов. Отсутствие кэширования кода операции также может вызывать высокую загрузку процессора.