NGINX: настройка сервера и PHP-FPM

By | 10/02/2014
 

nginx_logo

Настройки 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


  •  

    Полезная подборка для начала. Спасибо