Это статья из цикла стетей моего небольшого HowTo по Debian Jessie.
Современный Интернет трудно представить без языка PHP, но возможностей работать с PHP из коробки нет ни у кого среди WEB-серверов. С Apache2 мы уже разобрались, установив для него модуль php, а вот с Nginx не так просто — он умеет работать с PHP по протоколу CGI. Наиболее прогрессивной вариацией CGI на сегодняшний день является FastCGI, а менеджер процессов для него — PHP-FPM. Он есть в стандартных репозиториях Debian под именем php5-fpm.
Установим:
gw:~$ sudo apt-get install php5-fpm
Также для PHP наверняка понадобятся некоторые модули, если чегото не хватит — доустановим в процессе разворачивания сайтов:
gw:~$ sudo apt-get install php5-curl php5-mcrypt php5-mysql
Не забываем добавить сервис в автозагрузку:
gw:~$ sudo systemctl enable php5-fpm.service
Теперь к настройкам.
После установки пакетов у вас появится отдельная директория для настроек php-fpm — /etc/php5/fpm
В ней расположен основной конфиг сервиса — /etc/php5/fpm/php-fpm.conf Настраивать я там особо ничего не стал, просто проверил чтобы была настройка с инклудами пулов:
...
include=/etc/php5/fpm/pool.d/*.conf
...
Хорошим правилом на хостинге где много сайтов под каждый сайт настраивать отдельного системного пользователя и отдельный php пул. Это дает возможность гибко настраивать php для каждого отдельного сайта, а также, «изолировать» на уровне php сайты друг от друга. Настройка пулов совсем несложная. Конфиги расположены в директории /etc/php5/fpm/pool.d По умолчанию в php-fpm есть один пул — www с конфигом — /etc/php5/fpm/pool.d/www.conf Я обычно выключаю данный конфиг простым переименованием файла в example или default:
gw:~$ sudo mv /etc/php5/fpm/pool.d/www.conf /etc/php5/fpm/pool.d/default
и потом использую в качетсве шаблона при создании своих пулов. Как и обещал, в следующей статье про WEB я приведу примеры конфигов двух вариантов запуска пулов php-fpm: в chroot и без него. А сейчас хочу просто перечислить основные настройки пулов и коротко их описать.
Название пула. В самом верху конфига в квадратных скобках пишут название пула, например:
[www] или [somepool] и тп
Пользователь и группа:
Это очень важный параметр, имя пользователя и группа от которого будут запускаться php-процессы. Например:
user = www-data
group = www-data
Где слушаем подключения:
Может быть как TCP сокет, так и Unix сокет. Если указать только номер TCP порта, значит слушать этот порт на всех интерфейсах. Например:
listen = /var/run/php5-fpm.sock
listen = 127.0.0.1:9001
listen = 9001
Если в качетве listen используется Unix сокет — то нужны дополнительные параметры по правам доступа и владельцу, также обращаю внимание на то что user от которого запущен процесс пула должен иметь права записи на сокет, иначе работать не будет:
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
С каких ip принимать запросы:
Используется в случае listen TCP сокета на всех интерфейсах. Я бы рекомендовал закрывать фаерволом, но тем не менее на уровне сервиса можно контроллировать доступ к сокету просто перечислив необходимые ip — остальные «идут лесом» Например розрешим доступ только с двух ip:
listen.allowed_clients = 192.168.1.100, 192.168.1.200
Настройка менеджера процессов, это очень важная часть конфига:
pm =
pm.max_children =
pm.start_servers =
pm.min_spare_servers =
pm.max_spare_servers =
Тут трудно описать лучше чем в официальной документации, поэтому лучше прочтите сами и настраивайте с понимаением дела.
Время в секундах после которого простаивающие процессы будут убиты, работает только при pm = ondemand:
pm.process_idle_timeout =
Количество реквестов после которого fastcgi процесс полностью перезапустится:
Это очень полезная опция, реально может помочь при работе с проектом в котором есть баги с утечками памяти. Конечно же это не решает проблему кривого кода, но зато существенно сокращает количество сегфолтов.
Вцелом хочу подитожить — грамотная настройка pm* опций в пуле php-fpm помогает «держать на плаву» даже самые безнадежные php поделия 🙂
Статистика пула:
Полезная опция для мониторинга и статистики, включить можно например так:
pm.status_path = /$pool-status
после чего настраиваем проксирование некоторого локейшена в домене localhost на данный URL. Пример:
server {
listen 127.0.0.1:901;
location = /backend-status {
access_log off;
fastcgi_pass 127.0.0.1:9001;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
include fastcgi_params;
allow 127.0.0.1;
deny all;
}
}
после перезапуска nginx мы можем посмотреть что же там за статистика пула:
gw:~$ curl http://localhost:901/fpm-status
pool: backend
process manager: dynamic
start time: 05/Nov/2015:18:19:39 +0000
start since: 40412
accepted conn: 5378
listen queue: 0
max listen queue: 0
listen queue len: 65535
idle processes: 9
active processes: 1
total processes: 10
max active processes: 3
max children reached: 0
slow requests: 0
gw:~$
эти данные можно анализировать системой мониторинга, накапливать статистику, рисовать графики, обложить триггерами и оповещать ответственных в случай беды … но это уже совсем другая история.
Также для мониторинга доступности можно использовать более простой механизм ping-pong:
Значение по умолчанию /ping. Если данный URI спроксировать nginx-ом по образу и подобию приведенному выше, то в ответ будем получать 200-ку и некоторый ответ, который по умолчанию pong но можно задать кастомный следующей опцией:
Очень полезная фишка для простейшего мониторинга доступности сервиса.
Лог запросов, для дебага незаменимая опция:
Просто задаем путь к логу, например так:
access.log = /var/log/php-fpm/$pool_access.log
Формат лога доступа:
Огромный выбор различных параметров, смотрите сами в дефолтном конфиге для пула www.
Чаще на практике бывает что весь лог доступа не нужен, нужны только заведомо проблемные запросы. Таковыми являются те что долго выполняются. Для таких случаев есть отдельная опция — slowlog:
задает путь к файлу, например:
slowlog = /var/log/php-fpm/$pool_slow.log
а следующая опция задает время выполнения, после которого мы считаем запрос «медленным»:
request_slowlog_timeout =
А это опция для особо злых запросов:
request_terminate_timeout =
медленные запросы могут быть реальной проблемой. К тому же в какойто момент компиляция php файла по неким причинам может вообще затянуться на века … создавая никому ненужную нагрузку на сервер. Для таких случаев придумана данная опция, если выставить ее к примеру 10 секунд, то все запросы обрабатывающиеся fastcgi процессом более 10 секунд будут просто убиваться pm-ом.
Максимальное количество открытых файлов, глобально задано операционной системой, но можно и явно задать для пула:
Корневая директория для процессов пула, очень полезная опция для повышения безопасности. Особенно для shared-хостингов.
Перенаправлять с воркеров stdout и stderr в родительский процесс.
Это дает возможность логировать результаты работы процессов. Существенно помогает в дебаге, но уменьшает производительность, по умолчанию выключено, для включения задайте значение yes
Розширения принимаемые для обработки можно задать явно:
security.limit_extensions =
Например:
security.limit_extensions = .php .php5
Файлы с другими розширениями обрабатываться не будут.
Также в каждом пуле можно отдельно задать любые нужные вас переменные окружения. Например:
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
Ну и напоследок — переназначение глобальных настроек php.ini. Например:
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] = 16M
Конкретные примеры будут приведены в следующей статье, а на данный момент все …
Хай щастить!
«Існую, оскільки нікому невідомий»