Назад | Перейти на главную страницу

php-fpm использует много процессора

Я использую wordpress на Ubuntu 12.04 с Nginx + php-fpm на моем VPS. Имеется 2 ядра процессора + 4096Мб памяти.

Я переместил базу данных mysql на другой сервер и установил удаленный доступ. Одновременно в сети бывает около 300 посетителей, и php-fpm действительно сильно загружает процессор:

Я также использую APC-cache и batcache для wordpress.

Конфигурация php-fpm:

listen = /var/run/fpm-macradar.sock
;listen.backlog = -1

pm = ondemand
pm.max_children = 30
pm.start_servers = 15
pm.min_spare_servers = 10
pm.max_spare_servers = 20
;pm.process_idle_timeout = 10s;
pm.max_requests = 500

pm.status_path = /status

chdir = /

request_slowlog_timeout = 60s
slowlog = /var/log/$pool.log.slow

request_terminate_timeout = 120s
rlimit_files = 131072
rlimit_core = unlimited
catch_workers_output = yes

;php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 128M

Любая помощь будет оценена

Это старый вопрос, но сегодня кто-то ответил на него, редактируя сообщение.

Хотя установка плагина кэширования Wordpress может быть эффективной, это по-прежнему означает, что PHP выполняется, что относительно медленно. Если некоторые из посетителей вашего веб-сайта анонимны (т.е. не вошли в систему), вы можете выполнить кэширование страниц (fastcgi_cache) в Nginx, что позволит вообще избежать вызова PHP, что значительно снижает использование ЦП и улучшает время отклика. Чтобы страница была полезной, ее можно кэшировать всего на 1 секунду, или, если сайт довольно статичен, вы можете отложить это на день или больше. Сложная часть - это очистка кеша при публикации изменений, но у меня есть решение - см. Ниже.

Прочтите учебник, который я написал на LEMP. Эта первая часть дает вам файлы конфигурации для загрузки, они хорошо прокомментированы, а последующие части руководства объясняют их. Также есть отличная статья от Nginx о микрокеширование.

Если у вас только два процессора и 30 дочерних элементов параллельно, вы выполняете то количество процессов, которое поддерживает ваш процессор. Когда несколько дочерних элементов пытаются работать, у каждого из них меньше ЦП, и в результате все идет медленнее, плюс накладные расходы ЦП. Это действительно важно в случае, если WordPress использует много ЦП для каждого запроса.

Лучше уменьшить количество максимум до 2 или 3 потомков, и nginx, отвечающий за управление очередью соединений, запросы не теряет.

Когда FPM является «ondemand», вам нужно только определить pm.max_children, в этом случае:

pm.max_children = 2 

Надеюсь, вы сочтете это полезным.