Содержание
Настройки NGINX
Основные параметры конфигурации
Первым запускается “мастер” процесс /usr/sbin/nginx, который открывает необходимые порты и запускает количество worker_processes, указанное в конфигурации от имени пользователя, который указан там же. Кроме того, он записывает свой PID в файл /var/run/nginx.pid:
# ps aux | grep "nginx: master" | grep -v grep root 7599 0.0 0.0 47488 556 ? Ss 13:47 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
# cat /var/run/nginx.pid 7599
Таким образом, “ветвь процессов” NGINX выглядит как: master_process > worker_processes * N, где N – количество worker_processes в конфигурации:
# ps aux | grep nginx | grep -v grep root 7599 0.0 0.0 47488 556 ? Ss 13:47 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 7601 0.0 0.2 48700 2632 ? S 13:47 0:05 nginx: worker process
# cat /etc/nginx/nginx.conf | grep worker
worker_processes 1;
worker_connections 1024;
Worker-ы не являются multi-threaded процессами, поэтому они не могут перераспределять потоки, обрабатывающие подключения по разным процессорам.
worker_processes можно установить либо по количеству ядер/процессоров, либо в auto – тогда NGINX попытается сам определить оптимальное значение:
worker_processes auto;
worker_connection – количество соединений, которые будут обрабатывать worker_processes (т.е. max_connection для вашего NGINX будет worker_connections * worker_processes):
Так же учитываются соединения с “локальными” ресурсами – например, PHP-FPM или Apache HTTP.
По соображениям безопасности – можно отключить server_tokens:
server_tokens off;
В таком случае – NGINX не будет передавать свою версию в сообщениях об ошибках и в поле “Server” заголовка ответа.
client_max_body_size – если у вас возникает ошибка “Request Entity Too Large” (413) – увеличьте значение client_max_body_size, т.к. по умолчанию оно только 1 МБ:
client_max_body_size 20m;
Для ускорения загрузки файлов – можно увеличить client_body_buffer_size (по-умолчанию 16KB в х64):
client_body_buffer_size 128k;
Подробнее – тут>>>.
Кеширование статических файлов браузерами
Что бы браузеры хранили файлы в своём кеше, вместо загрузки их с сервера каждый раз, можно передать HTTP-заголовок Expires:
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}
Подробнее – тут>>>.
Запрет доступа к файлам
Что бы запретить доступ к файлам, начинающимся с точки – добавьте:
location ~ /. {
deny all;
}
Например, что бы запретить доступ к .htaccess и .htpasswd:
location ~ /.ht {
deny all;
}
Запретить доступ к файлам php в каталогах uploads и files:
location ~* /(?:uploads|files)/.*.php$ {
deny all;
}
Настройки для PHP-FPM
Перезапуск потоков
emergency_restart_threshold – указывает количество процессов-потомков (или “дочерних процессов”, кому как нравится) PHP-FPM, которые в случае получения сигналов SIGSEGV или SIGBUS за промежуток времени, заданный в emergency_restart_interval вызовут перезагрузку PHP-FPM.
Например:
emergency_restart_threshold = 10 emergency_restart_interval = 1m
Если 10 дочерних процессов PHP-FPM в течении 1 минуты получат ошибку SIGSEGV (Segmentation fault) или SIGBUS (Bus error) – то PHP-FPM будет перезапущен.
По-умолчанию отключено.
process_control_timeout – задаёт интервал в секундах, в течении которого потомки ждут ответа от PHP-FPM-мастера. Если ответа не будет – процесс будет пересоздан. По-умолчанию отключено:
process_control_timeout = 10
Эти настройки необходимо добавлять в основной файл настроек PHP-FPM , в CentOS это /etc/php-fpm.conf.
Настройки PHP-FPM Process Manager (pm)
Сам PM (pm) может запускаться по-разному:
static– фиксированное число дочерних процессов (pm.max_children).ondemand– число процессов, порождающихся по требованию (когда появляются запросы, в отличии от опцииdynamic, когда стартует определенное количество процессов, равноеpm.start_servers, вместе с запуском службы.- dynamic – динамически изменяющееся число дочерних процессов, задается на основании следующих директив:
pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
Например:
pm dynamic
pm.start_servers – количество дочерних процессов, которые будет создавать PM при старте PHP-FMP (только если pm dynamic);
pm.min_spare_servers – количество процессов, которые должны оставаться в idle, как “запасные”, ожидая задач на выполнение, если количество меньше – будут созданы новые;
pm.max_spare_servers – наоборот, максимальное количество процессов, которые должны оставаться в idle,если количество больше – некоторые потомки будут уничтожены;
pm.max_requests – количество запросов процесса, после которого он будет пересоздан, полезно для предотвращения утечек памяти (memory-leak);
pm.max_children – максимальное количество процессов-потомков, которое будет создано PM.
Оптимальное значение для max_children приблизительно можно подсчитать так:
запустить NGINX; выполнить обращение к самой “тяжёлой” странице PHP; открыть top или посмотреть в ps количество занятой RSS памяти, например:
# while true; do curl http://rtfm.co.ua &> /dev/null; sleep 1; done
теперь – получаем значение занятой памяти:
# ps aux | grep -E 'rtfm.*php-fpm' | head -n 1 | awk '{print $6}'
54796
53 МБ на один процесс.
Далее, предположим вы готовы выделить под PHP-скрипты 1 гигабайт памяти, тогда:
1024 МБ / 53 МБ = 19 pm.max_children.
Это, конечно, очень неточное решение.
К примеру, реально занятая память PHP-FPM процессами на самом деле будет меньше, например из данных ps_mem:
571.4 MiB + 8.1 MiB = 579.5 MiB php-fpm (23)
Т.е. 25 МБ в среднем на каждый.
Некоторые полезные опции PHP-FPM
security.limit_extensions – ограничение типов файлов (по расширению), которые будут обрабатываться PHP-FPM.
Значение по-умолчанию – .php.
chroot и chdir – “корневая” директория для php-скриптов, и директория, с которой будут начинать выполнение скрипты. Хорошо описаны тут>>>.
Использование unix-сокетов вместо TCP-портов – хорошо описано тут>>>, но не забудьте добавить listen.owner, listen.group и listen.mode.
Указать отдельный лог-файл для ошибок PHP:
php_admin_value[error_log] = /var/log/php-fpm/www-error.log php_admin_flag[log_errors] = on
Записывать “медленные запросы” PHP можно указав лог в строке:
slowlog = /var/log/nginx/rtfm.co.ua-slow.log
А задать время, по истечении которого запрос будет считать “медленным” – с помощью:
request_slowlog_timeout = 5
Убить процесс, который выполняется больше 300 секунд:
request_terminate_timeout = 300s
Надеюсь, будет время добавить отдельный пост по настройке производительности и безопасности NGINX/PHP-FPM.
Ссылки по теме:
http://php.net
http://codex.wordpress.org
http://wiki.nginx.org/Main
http://www.if-not-true-then-false.com
https://stephentanner.com
http://help.ubuntu.ru
http://ae.koroglu.org
http://myjeeva.com
