Оптимизация Nginx + PHP-FPM для 5 миллионов ежедневных просмотров страниц. Php fpm оптимизация

Используем ‘pm static’ для максимальной производительности

Давайте кратко рассмотрим, как лучше настроить PHP-FPM для высокой пропускной способности, низкой задержки и более стабильного использования процессора и памяти. В большинстве дефолтных настроек PHP-FPM есть строка с PM (process manager), установленным в dynamic, а также рекомендации по использованию ondemand, в том случае если вы столкнулись с проблемами доступной памяти. Однако, давайте взглянем в документацию на php.net и сравним оба варианта управления, а также сравним с моей любимой настройкой под высокую посещаемость... pm = static:

pm = dynamic – количество дочерних процессов устанавливается динамически, основываясь на следующих директивах: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.

pm = ondemand – процессы плодятся по требованию (при необходимости, в отличие от динамического варианта, где pm.start_servers запускаются при запуске сервиса).

pm = static – количество дочерних процессов фиксировано директивой pm.max_children.

…вы можете посмотреть полный список директив php-fpm.conf для получения дополнительной информации.

Менеджер процессов (process manager) PHP-FPM-а схож с CPUFreq Governor

Это может показаться немного не по теме, но я надеюсь связать его с нашей оптимизацией PHP-FPM. Да, все мы когда-то натыкались на проблемы с производительностью процессора, будь то ноутбук, виртуальная машина или выделенный сервер. Помните масштабирование частоты процессора? (CPUFreq governor) Эти параметры, доступные на *nix и Windows, могут повысить производительность и отзывчивость системы путем изменения настройки CPU governor с ondemand на performance. Сейчас давайте сравним описания и поищем сходства:

Governor = ondemand – Динамически увеличивает/уменьшает тактовую частоту процессора в зависимости от загруженности системы. Выводит до максимальной частоты, а потом уменьшает по мере увеличения времени простоя.

Governor = conservative – Похож на ondemand, но более экономный (предпочтение отдаётся меньшим тактовым частотам). Частота растёт более плавно.

Governor = performance – Поддерживает процессор(ы) на максимальной тактовой частоте.

… для дополнительной информации см. полный список настроек CPUFreq governor.

Заметили сходство? Я хотел сначала использовать это сравнение, чтобы более наглядно и лучше описать рекомендацию использовать pm static для PHP-FPM в качестве вашего первого выбора.

Настройка performance в CPU governor – это довольно безопасный прирост производительности, потому что это почти полностью зависит от предела процессора вашего сервера. Но есть несколько побочных эффектов (при постоянном удерживании частоты вашего процессора на 100%) – такие, как нагрев, время автономной работы (ноутбук) и другие. Однако это действительно самый быстрый параметр для вашего процессора.

Использование pm = static для максимальной производительности вашего сервера

Настройка pm = static в PHP-FPM сильно зависит от того, сколько свободной памяти на сервере. В основном, если вы страдаете от нехватки памяти сервера, то pm ondemand или dynamic могут оказаться лучшими вариантами. С другой стороны, если у вас достаточно свободной памяти, вы можете избежать большей части накладных расходов менеджера процессов, установив pm static до максимальной емкости сервера. Другими словами, когда вы делаете расчёты, pm.static нужно установить на максимальное количество PHP-FPM процессов, которые могут выполняться без создания проблем доступности памяти или кеша; однако, не так высоко, чтобы перегрузить процессор(ы) и иметь кучу отложенных операций PHP-FPM-а.

На скриншоте выше, у этого сервера установлен pm = static и pm.max_children = 100, которые используют максимум около 10 ГБ из 32 ГБ установленных. Обратите внимание на выделенные столбцы, которые говорят сами за себя. В момент этого скриншота было около 200 активных пользователей (за последние 60 секунд). При таком уровне пользователей, около 70% из дочерних процессов PHP-FPM по-прежнему простаивает. Это означает, что PHP-FPM настроен так, что всегда использует максимум возможности ресурсов вашего сервера вне зависимости от текущего трафика. Процессы, находящиеся в простое, остаются "онлайн", ожидая всплеска трафика, чтобы мгновенно ответить, а не ждать PM пока он насоздаёт дочерних процессов, а потом ещё будет убивать их после того, как истечёт pm.process_idle_timeout. В моих настройках pm.max_requests установлен чрезвычайно высоко, т. к. это боевой сервер, в котором не должно быть утечки памяти в PHP. Вы можете использовать pm.max_requests = 0 при статическом режиме, если у вас есть 110% уверенности в ваших нынешних и будущих PHP-скриптах. Однако, рекомендуется перезапускать скрипты время от времени. Устанавливайте ваше количество запросов до перезапуска в наибольшее значение, чтобы избежать оверхеда PM-а. Например, как минимум pm.max_requests = 1000... основывайтесь на вашем количестве pm.max_children и количестве запросов в секунду.

На скриншоте используется линуксовый top. Тут отображаются не все процессы, а только та часть, что вместилась в ваше терминальное окно. В нашем случае отсортированных по %CPU (потреблению процессора). Чтобы увидеть все 100 PHP-FPM процессов, вы можете использовать что-то вроде этого:

top -bn1 | grep php-fpm

Когда использовать pm ondemand и dynamic

Используя режим dynamic, вы можете наткнуться на подобные ошибки:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Вы можете попытаться увеличить/изменить настройки и по-прежнему видеть ту же ошибку. Подобная ситуация описана в этом вопросе на Serverfault. В таком случае, pm.min была слишком низкой, а т. к. трафик сильно колеблется, режим dynamic достаточно сложно настроить правильно. Общий совет: используйте ondemand, как советуют в этом же вопросе. Однако что еще хуже, т. к. ondemand будет завершать процессы в простое вплоть до 0 когда мало трафика, то после вы получите настолько много накладных расходов, насколько скакнёт трафик. Если, конечно, вы не установите время ожидания чрезвычайно высоким. В этом случае вам просто нужно использовать pm = static + высокий pm.max_requests.

Несмотря на это, всё-таки режим dynamic и особенно ondemand может спасти вас когда у вас есть несколько PHP-FPM Pool-ов. Например, при хостинге нескольких cPanel-аккаунтов или нескольких сайтов под разными pool-ами. У меня есть сервер, к примеру, со 100+ аккаунтами cPanel и около 200+ доменами, и для режима static или даже dynamic было бы невозможно поддерживать хорошую производительность. И только режим ondemand справляется с этим хорошо, т. к. более двух третей из веб-сайтов имеют маленький трафик, а с ondemand это значит, что все "дети" будут завершены, экономя тонны серверной памяти! К счастью, разработчики cPanel это поняли и теперь по умолчанию стоит ondemand. Ранее с динамическим режимом по умолчанию, использовать PHP-FPM на общих серверах было не вариантом. Многие использовали suPHP , потому что dynamic-режим съедал память даже в простое PHP-FPM Pool-ов. Вероятно, если вы имеете хороший трафик, вы не будете размещены на сервере с большим количеством PHP-FPM Pool-ов (shared hosting).

Заключение

Когда дело доходит до PHP-FPM, раз вы начали получать серьезный трафик, то режимы ondemand и dynamic могут ограничить пропускную способность из-за свойственного оверхеда. Исследуйте вашу систему и установите количество процессов в наибольшее, с которым справится ваш сервер. Начните с pm.max_children, установленным на основе максимального использования режимов dynamic или ondemand, а затем увеличивайте до точки, где память и процессор остаются не перегруженными. Вы заметите, что с pm = static, т. к. вы держите всё в памяти, всплески трафика со временем будут меньше влиять на всплески загрузки процессора, а показатели загрузки и средней загрузки станут более сглаженными. Средний размер вашего PHP-FPM-процесса будет зависеть от конкретного веб-сервера, требующего ручной настройки, вот почему автоматизированные режимы – dynamic и ondemand – являются более популярными рекомендациями. Надеюсь, это была полезная статья.

phpprofi.ru

Оптимизация PHP-FPM: максимальная производительность и pm static

pm = static – количество дочерних процессов фиксировано директивой pm.max_children.

…вы можете посмотреть полный список директив php-fpm.conf для получения дополнительной информации.

Менеджер процессов (process manager) PHP-FPM-а схож с CPUFreq Governor

Governor = performance – Поддерживает процессор(ы) на максимальной тактовой частоте.

… для дополнительной информации см. полный список настроек CPUFreq governor.

Использование pm = static для максимальной производительности вашего сервера

У этого сервера установлен pm = static и pm.max_children = 100, которые используют максимум около 10 ГБ из 32 ГБ установленных. Обратите внимание на выделенные столбцы, которые говорят сами за себя. В момент этого скриншота было около 200 активных пользователей (за последние 60 секунд). При таком уровне пользователей, около 70% из дочерних процессов PHP-FPM по-прежнему простаивает. Это означает, что PHP-FPM настроен так, что всегда использует максимум возможности ресурсов вашего сервера вне зависимости от текущего трафика. Процессы, находящиеся в простое, остаются «онлайн», ожидая всплеска трафика, чтобы мгновенно ответить, а не ждать PM пока он насоздаёт дочерних процессов, а потом ещё будет убивать их после того, как истечёт pm.process_idle_timeout. В моих настройках pm.max_requests установлен чрезвычайно высоко, т. к. это боевой сервер, в котором не должно быть утечки памяти в PHP. Вы можете использовать pm.max_requests = 0 при статическом режиме, если у вас есть 110% уверенности в ваших нынешних и будущих PHP-скриптах. Однако, рекомендуется перезапускать скрипты время от времени. Устанавливайте ваше количество запросов до перезапуска в наибольшее значение, чтобы избежать оверхеда PM-а. Например, как минимум pm.max_requests = 1000… основывайтесь на вашем количестве pm.max_children и количестве запросов в секунду.

Тут отображаются не все процессы, а только та часть, что вместилась в ваше терминальное окно. В нашем случае отсортированных по %CPU (потреблению процессора). Чтобы увидеть все 100 PHP-FPM процессов, вы можете использовать что-то вроде этого:

top -bn1 | grep php-fpm

Когда использовать pm ondemand и dynamic

Используя режим dynamic, вы можете наткнуться на подобные ошибки:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Несмотря на это, всё-таки режим dynamic и особенно ondemand может спасти вас когда у вас есть несколько PHP-FPM Pool-ов. Например, при хостинге нескольких cPanel-аккаунтов или нескольких сайтов под разными pool-ами. У меня есть сервер, к примеру, со 100+ аккаунтами cPanel и около 200+ доменами, и для режима static или даже dynamic было бы невозможно поддерживать хорошую производительность. И только режим ondemand справляется с этим хорошо, т. к. более двух третей из веб-сайтов имеют маленький трафик, а с ondemand это значит, что все «дети» будут завершены, экономя тонны серверной памяти! К счастью, разработчики cPanel это поняли и теперь по умолчанию стоит ondemand. Ранее с динамическим режимом по умолчанию, использовать PHP-FPM на общих серверах было не вариантом. Многие использовали suPHP , потому что dynamic-режим съедал память даже в простое PHP-FPM Pool-ов. Вероятно, если вы имеете хороший трафик, вы не будете размещены на сервере с большим количеством PHP-FPM Pool-ов (shared hosting).

Заключение

Источник: https://phpprofi.ru/blogs/post/70

PHP-FPM. Настройка и тюнинг - helpany.ru

; Имя пула (не должно совпадать с именем пользователя в системе)

[www]

; Адрес с портом или сокет, на который будут идти запросы FastCGI запросы

listen = /tmp/php-fpm.sock

; listen.backlog это параметр backlog функции TCP listen того сокета, на котором висит fpm

; параметр backlog отвечает за размер очереди одновременно ожидающих подключений к сокету,

; то есть инициированных (SYN - SYN,ACK - ACK), но еще не принятых сервером (established)

; -1 использует текущий hard limit net.core.somaxconn

listen.backlog = -1

; Список ip клиентов, которым разрешено подключение

listen.allowed_clients = 127.0.0.1

; Владелец Unix-сокета, его группа и права доступа к сокету

listen.owner = nginx

listen.group = nginx

listen.mode = 0660

; Воркеры пула будут работать от имени указанного пользователя и группы

user = nginx

group = nginx

; Метод порождения процессов

; static - строго постоянное количество процессов-обработчиков,

; dynamic - переменное количество обработчиков, для которых

; указывается минимальное и максимальное

; количество процессов, а также количество процессов-обработчиков

; "на подхвате", которые держатся

; готовыми на случай внезапного наплыва нагрузки, чтобы

; не терять время на порождение новых процессов-обработчиков,

; ondemand - режим, при котором обработчики порождаются только

; при поступлении запросов и завершаются спустя указанный период простоя.

pm = dynamic

; Число дочерних процессов, созданных для static, либо

; максимальное число, когда pm установлен в dynamic

pm.max_children = 7

; Число дочерних процессов, содаваемых при запуске (только dynamic)

pm.start_servers = 5

; Желаемое минимальное число неактивных процессов сервера (только dynamic)

pm.min_spare_servers = 5

; Желаемое максимальное число неактивных процессов сервера (только dynamic)

pm.max_spare_servers = 7

; Число запросов дочернего процесса, после которого процесс будет перезапущен

; Тут можно ограничить количество запросов, последовательно обслуживаемых одним процессом

; После этого процесс будет завершён и запущен снова - это может помочь от утечек памяти

pm.max_requests = 300

; Ссылка, по которой можно посмотреть страницу состояния FPM

;pm.status_path = /status

; Ссылка на ping-страницу мониторинга FPM (можно собрать своеобразный health-check)

;ping.path = /ping

; Эта директива может быть использована на настройки ответа на ping-запрос

;ping.response = pong

; Таймаут для обслуживания одного запроса, после чего рабочий

; процесс будет завершен (если не сработает max_execution_time)

;request_terminate_timeout = 0

; Таймаут для обслуживания одного запроса, после чего PHP backtrace

; будет сохранен в файл 'showlog'

; Доступные единицы измерения: s(секунды), m(минуты), h(часы) или d(дни)

request_slowlog_timeout = 2s

; Лог-файл для медленных запросов

slowlog = /var/log/php-fpm/www-slow.log

; Устанавливает лимит дескрипторов открытых файлов rlimit.

; Значение по умолчанию: определяется значением системы.

;rlimit_files = 1024

; Устанавливает максимальное количество используемых ядер rlimit

;rlimit_core = 0

; Директория chroot окружения при старте

;chroot =

; Chdir изменяет текущую директорию при старте

;chdir = /var/www

; Перенаправление STDOUT и STDERR рабочего процесса в главный лог ошибок.

; Если не установлен, STDOUT и STDERR будут перенаправлены в /dev/null в

; соответствии со спецификацией FastCGI

;catch_workers_output = yes

; ограничение выполнение файлов по расширению имени

security.limit_extensions = .php .php3 .php4 .php5

; Передача переменных окружения и настроек PHP пулу

;env[HOSTNAME] = $HOSTNAME

;env[PATH] = /usr/local/bin:/usr/bin:/bin

;env[TMP] = /tmp

;env[TMPDIR] = /tmp

;env[TEMP] = /tmp

;php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f [email protected]

;php_flag[display_errors] = off

php_admin_value[error_log] = /var/log/php-fpm/www-error.log

php_admin_flag[log_errors] = on

;php_admin_value[memory_limit] = 128M

php_value[session.save_handler] = files

php_value[session.save_path] = /var/lib/php/session

helpany.ru

linux - Оптимизация Nginx + PHP-FPM для 5 миллионов ежедневных просмотров страниц

Мы запускаем несколько сайтов большого объема, которые вместе генерируют около 5 миллионов просмотров страниц в день. У нас есть самые перегруженные серверы, поскольку мы ожидаем роста, но у нас есть сообщения о нескольких активных пользователях, которые говорят, что сайт иногда медленный в первом просмотре страницы. Я видел это каждый раз в то время, когда первое просмотрение страницы занимает 3-5 секунд, а затем мгновенно после этого в течение остальной части дня. Это случилось со мной, возможно, дважды за последние 24 часа, поэтому этого недостаточно, чтобы понять, что происходит. Каждая страница на нашем сайте использует PHP, но в один из случаев, когда это случилось со мной, это было на странице PHP, которая не имеет каких-либо вызовов в базе данных, что заставляет меня думать, что проблема ограничена параметрами NGINX, PHP-FPM или сетью.

У нас есть 3 сервера NGINX, работающих за балансировщиком нагрузки. Наша база данных разделена на кластер. Я включил наши файлы конфигурации для nginx и php-fpm, а также наше текущее использование ОЗУ и статус PHP-FPM. Это основано на середине дня (средний трафик для нас). Пожалуйста, взгляните и сообщите мне, видите ли вы какие-либо красные флаги в моей настройке или какие-либо предложения по оптимизации.

Характеристики каждого сервера NGINX:

OS: CentOS 7 RAM: 128GB CPU: 32 cores (2.4Ghz each) Drives: 2xSSD on RAID 1

Использование ОЗУ (бесплатно -g)

total used free shared buff/cache available Mem: 125 15 10 3 100 103 Swap: 15 0 15

Статус PHP-FPM (IE: http://server1_ip/status)

pool: www process manager: dynamic start time: 03/Mar/2016:03:42:49 -0800 start since: 1171262 accepted conn: 69827961 listen queue: 0 max listen queue: 0 listen queue len: 0 idle processes: 1670 active processes: 1 total processes: 1671 max active processes: 440 max children reached: 0 slow requests: 0

Файл конфигурации php-fpm:

[www] user = nginx group = nginx listen = /var/opt/remi/php70/run/php-fpm/php-fpm.sock listen.owner = nginx listen.group = nginx listen.mode = 0660 listen.allowed_clients = 127.0.0.1 pm = dynamic pm.max_children = 6000 pm.start_servers = 1600 pm.min_spare_servers = 1500 pm.max_spare_servers = 2000 pm.max_requests = 1000 pm.status_path = /status slowlog = /var/opt/remi/php70/log/php-fpm/www-slow.log php_admin_value[error_log] = /var/opt/remi/php70/log/php-fpm/www-error.log php_admin_flag[log_errors] = on php_value[session.save_handler] = files php_value[session.save_path] = /var/opt/remi/php70/lib/php/session php_value[soap.wsdl_cache_dir] = /var/opt/remi/php70/lib/php/wsdlcache

Файл конфигурации nginx:

user nginx; worker_processes 32; error_log /var/log/nginx/error.log; pid /run/nginx.pid; events { worker_connections 1000; multi_accept on; use epoll; } http { log_format main '$remote_addr - $remote_user [$time_iso8601] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 10 10; send_timeout 60; types_hash_max_size 2048; client_max_body_size 50M; client_body_buffer_size 5m; client_body_timeout 60; client_header_timeout 60; fastcgi_buffers 256 16k; fastcgi_buffer_size 128k; fastcgi_connect_timeout 60s; fastcgi_send_timeout 60s; fastcgi_read_timeout 60s; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; reset_timedout_connection on; server_names_hash_bucket_size 100; #compression gzip on; gzip_vary on; gzip_min_length 10240; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/javascript application/xml; gzip_disable "MSIE [1-6]\."; include /etc/nginx/mime.types; default_type application/octet-stream; # Load modular configuration files from the /etc/nginx/conf.d directory. # See http://nginx.org/en/docs/ngx_core_module.html#include # for more information. include /etc/nginx/conf.d/*.conf; server { listen 80 default_server; listen [::]:80 default_server; server_name domain1.com; root /folderpath; location / { index index.php; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } #server status location /server-status { stub_status on; access_log off; auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; } location = /status { access_log off; allow 127.0.0.1; auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; fastcgi_pass unix:/var/opt/remi/php70/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/var/opt/remi/php70/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }

UPDATE:

Я установил opcache в соответствии с предложением ниже. Не уверен, исправляет проблему. Вот мои настройки

opcache.enable=1 opcache.memory_consumption=1024 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=32531 opcache.max_wasted_percentage=10

qaru.site

оптимизация - Очень долго работает связка nginx+php5-fpm

Настроил сервер на debian jessie. Установлено:

nginx version: nginx/1.8.0 PHP 5.6.9-0+deb8u1 (cli) (built: Jun 5 2015 11:03:27)

Организована связка так:

location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_pass 127.0.0.1:9000; #fastcgi_pass unix:/var/run/php5-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param REMOTE_ADDR $remote_addr; # PATH_INFO и PATH_TRANSLATED могут быть опущены, но стандарт RFC 3875 определяет для CGI fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name; fastcgi_read_timeout 300;

Время загрузки страниц сайта около 30 секунд. Для теста создал test.php с одной строчкой "echo 123;". 15-20 секунд ответ сервера. Много гуглил, много эксперементировал с настройками fpm, но результат не изменяется. Куда еще посмотреть?

/var/log/nginx/error.log

2015/06/25 13:17:39 [alert] 30302#30302: *11394 open socket #60 left in connection 78 2015/06/25 13:17:39 [alert] 30302#30302: *11403 open socket #76 left in connection 86 2015/06/25 13:17:39 [alert] 30302#30302: *11771 open socket #94 left in connection 101 2015/06/25 13:17:39 [alert] 30302#30302: aborting 2015/06/25 13:23:16 [alert] 32173#32173: *4658 open socket #23 left in connection 17 2015/06/25 13:23:16 [alert] 32167#32167: *3854 open socket #24 left in connection 41 2015/06/25 13:23:16 [alert] 32173#32173: *4611 open socket #64 left in connection 43 2015/06/25 13:23:16 [alert] 32173#32173: *4661 open socket #68 left in connection 47 2015/06/25 13:23:16 [alert] 32167#32167: aborting 2015/06/25 13:23:16 [alert] 32173#32173: aborting 2015/06/25 13:23:53 [alert] 961#961: *180 open socket #33 left in connection 8 2015/06/25 13:23:53 [alert] 962#962: *509 open socket #29 left in connection 7 2015/06/25 13:23:53 [alert] 961#961: *339 open socket #57 left in connection 35 2015/06/25 13:23:53 [alert] 962#962: *536 open socket #30 left in connection 9 2015/06/25 13:23:53 [alert] 961#961: *341 open socket #58 left in connection 36 2015/06/25 13:23:53 [alert] 962#962: *554 open socket #32 left in connection 10 2015/06/25 13:23:53 [alert] 961#961: aborting 2015/06/25 13:23:53 [alert] 962#962: aborting

tail -50 /var/log/php5-fpm.log

[25-Jun-2015 13:00:17] NOTICE: [pool www] child 25595 exited with code 0 after 1949.912319 seconds from start [25-Jun-2015 13:00:17] NOTICE: [pool www] child 26970 started [25-Jun-2015 13:00:36] NOTICE: [pool www] child 25610 exited with code 0 after 1963.430992 seconds from start [25-Jun-2015 13:00:36] NOTICE: [pool www] child 26994 started [25-Jun-2015 13:01:42] NOTICE: [pool www] child 25590 exited with code 0 after 2039.416889 seconds from start [25-Jun-2015 13:01:42] NOTICE: [pool www] child 30199 started [25-Jun-2015 13:01:53] NOTICE: [pool www] child 25604 exited with code 0 after 2041.622595 seconds from start [25-Jun-2015 13:01:53] NOTICE: [pool www] child 30200 started [25-Jun-2015 13:02:06] NOTICE: [pool www] child 25805 exited with code 0 after 1380.138459 seconds from start [25-Jun-2015 13:02:06] NOTICE: [pool www] child 30210 started [25-Jun-2015 13:02:18] NOTICE: [pool www] child 25582 exited with code 0 after 2079.261857 seconds from start [25-Jun-2015 13:02:18] NOTICE: [pool www] child 30220 started [25-Jun-2015 13:02:19] NOTICE: [pool www] child 25577 exited with code 0 after 2082.618852 seconds from start [25-Jun-2015 13:02:19] NOTICE: [pool www] child 30221 started [25-Jun-2015 13:02:35] NOTICE: [pool www] child 25486 exited with code 0 after 2547.216388 seconds from start [25-Jun-2015 13:02:35] NOTICE: [pool www] child 30222 started [25-Jun-2015 13:02:40] NOTICE: [pool www] child 25587 exited with code 0 after 2098.278808 seconds from start [25-Jun-2015 13:02:40] NOTICE: [pool www] child 30230 started [25-Jun-2015 13:03:07] NOTICE: [pool www] child 25720 exited with code 0 after 1823.929943 seconds from start [25-Jun-2015 13:03:07] NOTICE: [pool www] child 30250 started [25-Jun-2015 13:03:13] NOTICE: [pool www] child 25756 exited with code 0 after 1615.115781 seconds from start [25-Jun-2015 13:03:13] NOTICE: [pool www] child 30277 started [25-Jun-2015 13:04:01] NOTICE: Terminating ... [25-Jun-2015 13:04:01] NOTICE: exiting, bye-bye! [25-Jun-2015 13:04:01] NOTICE: configuration file /etc/php5/fpm/php-fpm.conf test is successful [25-Jun-2015 13:04:01] NOTICE: fpm is running, pid 30330 [25-Jun-2015 13:04:01] NOTICE: ready to handle connections [25-Jun-2015 13:04:01] NOTICE: systemd monitor interval set to 10000ms [25-Jun-2015 13:04:21] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 9 idle, and 36 total children [25-Jun-2015 13:04:57] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 8 idle, and 53 total children [25-Jun-2015 13:05:21] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 9 idle, and 78 total children [25-Jun-2015 13:05:48] WARNING: [pool www] server reached pm.max_children setting (100), consider raising it [25-Jun-2015 13:08:12] NOTICE: [pool www] child 30423 exited with code 0 after 186.354920 seconds from start [25-Jun-2015 13:08:12] NOTICE: [pool www] child 30528 started [25-Jun-2015 13:14:01] NOTICE: Terminating ... [25-Jun-2015 13:14:01] NOTICE: exiting, bye-bye! [25-Jun-2015 13:21:49] NOTICE: configuration file /etc/php5/fpm/php-fpm.conf test is successful [25-Jun-2015 13:21:49] NOTICE: fpm is running, pid 844 [25-Jun-2015 13:21:49] NOTICE: ready to handle connections [25-Jun-2015 13:21:49] NOTICE: systemd monitor interval set to 10000ms [25-Jun-2015 13:23:06] NOTICE: Term

inating ... [25-Jun-2015 13:23:06] NOTICE: exiting, bye-bye! [25-Jun-2015 13:23:06] NOTICE: configuration file /etc/php5/fpm/php-fpm.conf test is successful

[25-Jun-2015 13:23:06] NOTICE: fpm is running, pid 920 [25-Jun-2015 13:23:06] NOTICE: ready to handle connections [25-Jun-2015 13:23:06] NOTICE: systemd monitor interval set to 10000ms [25-Jun-2015 13:24:06] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

ru.stackoverflow.com

Оптимизация Nginx + PHP-FPM для более быстрого времени отклика (для Openx adserving)

Во-первых, слишком много рабочих, и лимиты слишком высоки. Максимальный рабочий счетчик только для php-fpm может немного заглушить ваш сервер. Отказ от ограничений на сервере не обязательно ускорит его, но может иметь противоположный эффект.

Количество рабочих: 20 не имеет смысла, если у вас нет 20-процессорной / основной машины, вы фактически нанесете отрицательный эффект, так как у рабочих будет чрезмерное переключение содержимого. Если вы используете двухъядерный процессор, должно быть достаточно 2 рабочих.
Рабочие соединения: Опять же, просто бросать лимит в небеса не решает ваших проблем. Если ваш вывод ulimit -n составляет примерно 1024, тогда ваши рабочие соединения должны быть установлены на 1024 или меньше (может быть, даже на 768), маловероятно, что у вас будет 2 x 1024 одновременных подключения, особенно с чем-то вроде PHP.
Расположение корня и настройки PHP относятся к http://wiki.nginx.org/Pitfalls , он лучше всего работает, если вы ставите свою корневую директиву на уровне сервера {}, а не на уровень местоположения. Как только вы это сделаете, вы можете использовать $ document_root $ fastcgi_script_name как значение SCRIPT_FILENAME, поскольку $ document_root будет автоматически распространяться на блоки местоположения под ним.
Вы можете обращаться с статическими файлами напрямую, другими словами:
location ~* \.(ico|css|js|gif|jpe?g|png)$ { expires max; add_header Pragma public; add_header Cache-Control "public, must-revalidate, proxy-revalidate"; }
Используйте ускоритель PHP, а именно APC (с apc.enabled = 1 в php.ini) или XCache, и помните о своих настройках php, таких как memory_limit. Например, если у вас есть только система с 2 ГБ баранов, у нее мало смысла разрешать 500 рабочих с ограничением по 128 Мбайт каждый. Особенно верно, если вы также используете другие службы на своем сервере.

Вы должны определенно уменьшить количество работников, поскольку я сомневаюсь, что у вас есть 20 ядер / процессоров. Кроме того, я бы посмотрел на ваш сервер базы данных, есть большая вероятность, что проблема там.

Кроме того, вы увеличили worker_rlimit_nofile до 50000 , надеюсь, вы знаете, что операционная система обычно устанавливает ограничение на 1024 (по умолчанию), вы можете попробовать запросить текущий предел, набрав ulimit -n

Вы можете поднять жесткий лимит NOFILE (количество открытых файлов), выполнив эту команду ulimit -n 50000 в init.d или посетите этот другой вопрос в , чтобы узнать, как использовать limits.conf для постоянного ограничения лимитов в системе.

у вас есть 20 процессоров или ядер на вашем компьютере? также возможно попробовать события со значением по умолчанию для вашей ОС ... возможно, больше процессов fcgi, а не больше nginx ... возможно, начиная с 2 - 4 рабочих nginx достаточно ...

Самый эффективный способ сделать серверную систему намного быстрее - использовать Facebook HipHop Virtual Machine (HHVM) вместо PHP (PHP не должен быть установлен больше).

HHVM использует перед процессором «Just in Time Compiler» и выполняет обычно PHP-код в 5-10 раз быстрее, чем сам PHP, он позволяет ладить с меньшим количеством серверов или меньших серверов и снижать энергопотребление по существу. Википедия использовала HHVM для снижения нагрузки на сервер ЦП на фактор 5: http://www.golem.de/news/php-facebooks-hhvm-macht-wikipedia-schneller-1501-111515.html

Он может быть установлен вместе с Nginx как пакет Linux и включен в Nginx очень легко, как FastCGI, и вскоре через несколько минут его можно протестировать через небольшой PHP-файл Hello World: https://github.com/facebook/hhvm/wiki/Getting-Started

Новый PHPNG PHPNG должен быть правдивым в соответствии с тестовыми испытаниями только на 30% быстрее.

спасибо за поддержку

code-examples.net

Настройка PHP-FPM для повышения производительности + Low Memory

Люди, обладающие характером, — это совесть общества.. (Р. Эмерсон).

PHP-FPM имеет конфигурацию по умолчанию, которая использует больше памяти, чем это необходимо. Она имеет запасные PHP-FPM процессы, готовые запускаться, занимая память в случае, если есть PHP код в обработки. Хотя это и не проблема, если у вас есть тонны оперативной памяти, это может быть проблемой для низкой VPS RAM и если вы используете агрессивное кэширование страниц, то это память используется без необходимости, которая может быть использована для MariaDB (MySQL) или для других важных процессов. Это руководство объясняет, как настроить конфигурацию Nginx с PHP-FPM работающем на PHP 7.0, чтобы использовать как можно меньше оперативной памяти, как это возможно.

Настройка PHP-FPM для повышения производительности + Low Memory

Откройте файл конфигурации PHP-FPM для PHP 7.0.

sudo nano /etc/php/7.0/fpm/pool.d/www.conf

Настройте следующие значения, как показано ниже, обратите внимание на ; перед pm.start_servers, pm.min_spare_servers и pm.max_spare_servers.

pm = ondemand означает, что дочерние процессы в PHP-FPM будут порождаться только при необходимости

pm.max_children это максимальное количество дочерних процессов, которые будут разрешены, 50 является достаточно либеральным, но если вы видите в своем архиве журналов что количество дочерних процессов превысило максимальное значение, то необходимо увеличить это значение

pm.process_idle_timeout убивает дочерние процессы после того, как они бездействовали в течение 10 секунд

pm.max_requests устанавливает максимальное количество запросов PHP для каждого дочернего процесса

pm = ondemand ; Число дочерних процессов, которые будет создано, когда pm установлен в 'static' и ; Максимальное число дочерних процессов, когда pm установлен в 'dynamic' и 'ondemand'. Это значение устанавливает ограничение на количество одновременных запросов, которые будут ; запускаться. Эквивалент директивы ApacheMaxClients в mpm_prefork. ; Эквивалентная переменная среды PHP_FCGI_CHILDREN в оригинальном PHP ; CGI. Ниже, по умолчанию основаны на сервере без использования значительных ресурсов. Не ; забудьте настройки часов.* чтобы соответствовать вашим потребностям. ; Примечание: используется, когда pm установлен в 'static', 'dynamic' или 'ondemand' ; Примечание: это значение является обязательным. pm.max_children = 50 ; Число дочерних процессов, созданных при запуске. ; Примечание: используется только тогда, когда pm установлен в "dynamic" ; Значение по умолчанию: min_spare_servers + (max_spare_servers - min_spare_servers) / 2 ;pm.start_servers = 2 ; Требуемое минимальное число неактивных процессов сервера. ; Примечание: используется только тогда, когда pm установлен в "dynamic" ; Примечание: обязательное, когда pm установлен в "dynamic" ;pm.min_spare_servers = 1 ; Требуемое максимальное число неактивных процессов сервера. ; Примечание: используется только тогда, когда pm установлен в "dynamic" ; Примечание: обязательное, когда pm установлен в "dynamic" ;pm.max_spare_servers = 3 ; Число секунд, по истечении которых бездействующий процесс будет убит. ; Примечание: используется только тогда, когда pm установлен в 'ondemand' ; Значение по умолчанию: 10s pm.process_idle_timeout = 10s; ; Число запросов после которых дочерний процесс будет перезапущен. Это может быть полезно во избежания утечек памяти в 3-й партии библиотек. Для ; бесконечной обработки запроса укажите '0'. Эквивалент PHP_FCGI_MAX_REQUESTS. ; Значение по Умолчанию: 0 pm.max_requests = 500

Проверьте правильность вашего синтаксиса конфигурации PHP-FPM

php-fpm7.0 -t

Вы должны увидеть, что конфигурация действует

[01-Jun-2017 15:51:34] NOTICE: configuration file /etc/php/7.0/fpm/php-fpm.conf test is successful

Теперь вы можете перезапустить php7.0-FPM

sudo service php7.0-fpm restart

Вы можете увидеть, что объем оперативной памяти используется значительно меньше.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Если статья понравилась, то поделитесь ей в социальных сетях:

andreyex.ru

Оптимизация Nginx + PHP-FPM для 5 миллионов ежедневных просмотров страниц. Php fpm оптимизация

Используем ‘pm static’ для максимальной производительности

Менеджер процессов (process manager) PHP-FPM-а схож с CPUFreq Governor

Использование pm = static для максимальной производительности вашего сервера

Когда использовать pm ondemand и dynamic

Заключение

Оптимизация PHP-FPM: максимальная производительность и pm static

Менеджер процессов (process manager) PHP-FPM-а схож с CPUFreq Governor

Использование pm = static для максимальной производительности вашего сервера

Когда использовать pm ondemand и dynamic

Заключение

Читайте также

PHP-FPM. Настройка и тюнинг - helpany.ru

linux - Оптимизация Nginx + PHP-FPM для 5 миллионов ежедневных просмотров страниц

оптимизация - Очень долго работает связка nginx+php5-fpm

Оптимизация Nginx + PHP-FPM для более быстрого времени отклика (для Openx adserving)

Настройка PHP-FPM для повышения производительности + Low Memory

Настройка PHP-FPM для повышения производительности + Low Memory

Если статья понравилась, то поделитесь ей в социальных сетях: