Php fpm не создает сокет

Обновлено: 02.07.2024

Интерпретатор языка программирования PHP может работать в нескольких режимах. Он может быть интегрирован в веб-сервер в виде специального модуля или использоваться как отдельный сервис PHP-FPM. Аббревиатура FPM расшифровывается как FastCGI Process Manager. Это сервис, который запускает несколько процессов, которые могут выполнять PHP скрипты.

PHP-FPM может получать скрипты, которые надо выполнить, с помощью TCP или Unix сокетов. Именно такой способ выполнения скриптов используется в Nginx. В этой статье мы рассмотрим как выполняется установка Nginx с PHP-FPM в Ubuntu.

Установка Nginx на Ubuntu 20.04

Установить Nginx можно двумя способами. Первый способ заключается в установки пакета из официального репозитория Ubuntu. На момент написания статьи (1 августа 2021 года) актуальной версией Nginx присутствующей в репозитории Ubuntu была версия 1.18.0. Данная версия считается устаревшей. Актуальной же версией считается 1.20.1 (по состоянию на 1 августа 2021 года).

1. Официальные репозитории Ubuntu

Если вы хотите установить версию Nginx из репозиториев Ubuntu необходимо выполнить следующие действия. Для начала обновляем списки пакетов при помощи команды:

sudo apt update

Для того, чтобы установить Nginx, достаточно выполнить команду:

sudo apt -y install nginx

После этого программу можно использовать. Проверка и настройка программы будет описана в разделах ниже.

2. Официальные репозитории Nginx

Второй способ заключается в установке последней версии Nginx из официальных репозиториев, которые предоставляют разработчики Nginx. Если вы хотите использовать данный метод установки, для начала необходимо обновить списки пакетов при помощи команды:

sudo apt update

Установите необходимые пакеты:

sudo apt -y install curl gnupg2 ca-certificates lsb-release

Далее у вас на выбор есть два пути – подключить репозиторий со стабильной версией nginx или подключить репозиторий с основной версией. Стабильная версия является более проверенной и работоспособной. Эту версию можно использовать, как и в тестовых средах так и на производственных. Основная версия не такая стабильная и может содержать ошибки. Данную версию не рекомендуется использовать в производственных средах.

Для подключения репозитория со стабильной версией nginx, выполните следующую команду:

echo "deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

Для подключения репозитория с основной версией nginx, выполните следующую команду:

echo "deb http://nginx.org/packages/mainline/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

Следующие шаги необходимо выполнять вне зависимости от выбранного репозитория. Импортируйте официальный ключ, используемый пакетным менеджером для проверки подлинности пакетов:

Проверьте, верный ли ключ был загружен:

gpg --dry-run --quiet --import --import-options import-show /tmp/nginx_signing.key

Вывод команды должен содержать полный отпечаток ключа 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62:

Переместите ключ в каталог доверенных ключей apt:

sudo mv /tmp/nginx_signing.key /etc/apt/trusted.gpg.d/nginx_signing.asc

Чтобы установить nginx, выполните следующие команды:

sudo apt update

sudo apt -y install nginx

Версия Nginx от разработчиков немного отличается от версии из официальных репозиториев. Все дополнительные конфигурационные файлы здесь находятся в папке /etc/nginx/conf.d. Если вы хотите использовать папки sites-available и sites-enabled, то необходимо их создать:

sudo mkdir /etc/nginx/sites-available
sudo mkdir /etc/nginx/sites-enabled

sudo vi /etc/nginx/nginx.conf

Затем перезапустите Nginx:

sudo nginx -s reload

3. Запуск Nginx

После установки пакета, проверяем что Nginx успешно запустился при помощи команды:

sudo systemctl status nginx

Если в статусе вместо active будет inactive (dead), то сервис необходимо запустить вручную при помощи команды:

sudo systemctl start nginx

Так же обратите внимание, что вы не можете запускать Apache и Nginx на одном порту. В таком случае вы получите ошибку nginx address already in use 80. Для корректной работы Nginx, необходимо будет отключить веб-сервер Apache (если он у вас используется) или изменить его порт с 80 (который используется по умолчанию) на другой свободный порт.

4. Настройка брандмауэра

По умолчанию брандмауэр закрывает все неразрешённые входящие подключения. Поэтому, чтобы к вашему веб-серверу можно было получить доступ извне, необходимо добавить его порт в исключения:

sudo ufw allow in 80/tcp

5. Проверка работы Nginx

После того, как Nginx будет запущен, он будет доступен по адресу сервера, на который он устанавливался. Вы можете проверить, всё ли работает, просто перейдя по адресу сервера, введя его в браузере. Для примера Nginx был установлен на localhost:

Установка PHP-FPM в Ubuntu

Следующим шагом будет установка интерпретатора языка программирования PHP и всех необходимых модулей для работы с PHP-FPM. Для установки всех необходимых модулей выполните команду:

sudo apt -y install php7.4 php7.4-cli php7.4-fpm php7.4-json php7.4-pdo php7.4-mysql php7.4-zip php7.4-gd php7.4-mbstring php7.4-curl php7.4-xml php-pear php7.4-bcmath

На момент написания статьи (1 августа 2021) актуальной версией PHP в официальных репозиториях Ubuntu считалась версия 7.4. Самая же последняя официальная версия PHP от разработчиков 8.0.9 (по состоянию на 29 июля 2021 года). После установки всех необходимых пакетов проверяем статус PHP-FPM:

systemctl status php7.4-fpm.service

Если в статусе вместо active будет inactive (dead), то сервис необходимо запустить вручную при помощи команды:

sudo systemctl start php7.4-fpm.service

После того, как сервис запустился, установка будет считаться выполненной.

Подключение Nginx к PHP-FPM

Чтобы принимать запросы FastCGI от Nginx, PHP-FPM может прослушивать сокет TCP/IP или UNIX сокет. Сокеты UNIX являются средством межпроцессного взаимодействия, которое обеспечивает эффективный обмен данными между процессами, работающими в одной и той же операционной системе, в то время как сокеты TCP/IP позволяют процессам обмениваться данными по сети.

Сокет UNIX - это особый тип файла - к нему применяются разрешения на доступ к файлам и каталогам (как в случае с любым другим типом файла UNIX), и его можно использовать для ограничения того, какие процессы на хосте могут читать и записывать в файл, (и, таким образом, общаться с внутренним сервером).

Таким образом, сокет UNIX является безопасным, поскольку его могут использовать только процессы на локальном хосте. Сокет TCP/IP может быть доступен из Интернета, и это может представлять угрозу безопасности, если не будут приняты дополнительные меры безопасности, такие как настройка брандмауэра.

Настройка PHP-FPM для прослушивания на сокете UNIX

Чтобы настроить PHP-FPM на прослушивание сокета UNIX, откройте файл конфигурации пула PHP-FPM по умолчанию, используя свой любимый текстовый редактор при помощи команды:

Затем найдите директиву listen и задайте для нее путь к файлу сокета UNIX следующим образом - listen = /run/php/php7.4-fpm.sock

Если вы используете сокет UNIX, вам также необходимо установить соответствующие разрешения на чтение/запись для файла, чтобы разрешить подключения с веб-сервера NGINX. По умолчанию Nginx работает как пользователь www-data в Ubuntu.

Найдите параметры listen.owner и listen.group и задайте им значение www-data. Также установите режим на 0660, для параметра listen.mode.

Настройка PHP-FPM для прослушивания через сокет TCP/IP

Хотя сокет UNIX быстрее сокета TCP/IP, он менее масштабируем, поскольку он может поддерживать межпроцессное взаимодействие только в одной и той же ОС. Если Nginx и внутренний сервер приложений (PHP-FPM) работают в разных системах, вам придется настроить php-fpm для прослушивания сокетов TCP/IP для удаленного подключения.

В файле конфигурации пула php-fpm установите адрес прослушивания, например: 127.0.0.1:9000. Убедитесь, что выбранный вами порт не используется другим процессом или службой в той же системе.

Найдите параметр listen и пропишите адрес - 127.0.0.1:9000:

Сохраните изменения и закройте файл. Установка Nginx php fpm практически завершена.

Настройка Nginx для работы php-fpm

После того, как вы настроили адрес, который прослушивает PHP-FPM, вам нужно настроить Nginx для запроса прокси к нему через этот адрес, используя параметр конфигурации fastcgi_pass, который располагается в файле конфигурации блока виртуального хоста.

Для примера, возьмем файл конфигурации стандартной странички сайта nginx которая открывается при первом запуске nginx, расположенный по следующему пути - /etc/nginx/conf.d/default.conf, откроем его для редактирования:

sudo nano /etc/nginx/conf.d/default.conf

Если вы настроили PHP-FPM для прослушивания на сокете UNIX, найдите блок местоположения для обработки файлов .php и установите следующие параметры для fastcgi:

\.php$ fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
>

Если используется TCP/IP сокет, замените значение в параметре fastcgi_pass на IP-адрес и порт сервера, на котором работает PHP-FPM FastCGI:

\.php$ fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
>

После внесения изменений в конфигурации Nginx проверьте правильность синтаксиса при помощи команды:

Далее вам необходимо перезапустить службы, чтобы применить изменения, используя для этого команды:

sudo systemctl restart nginx
sudo systemctl restart php7.4-fpm

После перезапуска служб, подключение считается выполненным успешно. Можно создать файл index.php со следующим содержимым:

sudo vi /var/www/html

Для дальнейшей настройки PHP-FPM воспользуйтесь статьей по настройке PHP-FPM на Ubuntu 20.04 – Настройка PHP-FPM

Удаление Nginx и PHP-FPM с Ubuntu

Чтобы полностью удалить Nginx и PHP-FPM из системы, достаточно удалить все пакеты, которые вы установили ранее:

sudo apt -y purge nginx php7.4 php7.4-cli php7.4-fpm php7.4-json php7.4-pdo php7.4-mysql php7.4-zip php7.4-gd php7.4-mbstring php7.4-curl php7.4-xml php-pear php7.4-bcmath

Команда purge позволяет удалить не только пакеты, но и их конфигурационные файлы. Если вы хотите оставить конфигурационные файлы, используйте команду remove.

Выводы

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Здравствуй, уважаемый пользователь Хабрахабра. Мое повествование будет о том, как подготовить почву для локальной веб-разработки проектов в операционной системе Ubuntu 16.04.1 LTS.

В данной статье хочется развеять и разъяснить возможные трудности связанные с установкой и настройкой ПО, которое требуется для современной веб-разработки, с которыми возможно сталкиваются начинающие разработчики и не только.

Технологии которые будут использованы в статье: nginx, php-fpm.

Перед началом повествования, хочу отметить, что я проделывал все эти действия на «голой» системе.
Я буду работать с пакетным менеджером aptitude. Так же рекомендую обновить индекс пакетов и сами пакеты перед установкой ПО. В статье мы проделаем эти действия вместе.

Установка пакетного менеджера aptitude, обновление индекса и пакетов

Обновляем пакеты (команда обновит все пакеты, для которых есть новые версии, если потребуется удаление пакетов, то оно будет выполнено).

Установка и настройка nginx (версия >= 1.10.0)

Проверяем версию, чтобы убедиться что не установили старую, то есть ниже 1.10.0.

Установку и запуск произвели, теперь пойдем в каталог туда куда установлен наш nginx и посмотрим на его структуру. Каталог nginx находится по такому пути:

Посмотреть содержимое директории можно командой ls, с флагами -la будет удобнее просматривать содержимое каталога (в действительности эту команду с конкретными флагами можно описать детальнее и вернее, но у нас сегодня другая тема).

Наc интересуют в данный момент два каталога, которые вы видите на скриншоте. Это каталоги sites-available и sites-enabled.

Давайте перейдем в каталог sites-available и начнем конфигурировать наш виртуальный хост (сайт).

Перед началом создания конфигурационного файла, проверим что лежит у нас в данном каталоге. В моей случае каталог не пустой, в нем уже есть конфигурационные файлы, я их затер, чтобы не вводить вас в заблуждение.

В случае установки nginx «с нуля», именно «с нуля», так как при удалении nginx командой
или конфигурационные файлы остаются и если вы вдруг будете не понимать, почему nginx не работает и захотите его переустановить (обычно к такому прибегают начинающие пользователи Linux), то и после переустановки он не будет корректно работать, из-за того что в старых конфигурационных файлах (они не удаляются после удаления командой remove) прописаны неверные настройки, их придется удалить, либо настроить верно, только тогда nginx заработает.

Рекомендую удалять командой sudo apt-get purge nginx или sudo apt purge nginx . Если вы используете пакетный менеджер aptitude, то команда sudo aptitude purge nginx удаляет пакет полностью со всеми зависимостями и конфигурационными файлами.

В этом каталоге будет по умолчанию один файл, с названием default. В нем будет конфигурационный файл с примером, с комментариями, его вы можете изучить на досуге, а можете и вовсе удалить (всегда можно обратиться к официальной документации).

Создадим свой конфигурационный файл, который будет соответствовать названию домена нашего локального сайта (или реального, если уже знаете его название). Это удобно, в будущем, когда будет много конфигурационных файлов, то это избавит вас от путаницы в них. У меня этот файл будет называться project.local.

Посмотрим что получилось.

Теперь откроем его в редакторе, я открою его в nano.

Видим что он у нас пустой. Теперь перейдем к формированию нашего файла. Нужно привести конфигурацию к такому виду, как написано ниже. Я опишу только жизненно важные директивы этого файла, описывать остальное не буду, так как это не является на данный момент важным, все-таки у нас тема базовой настройки. Этих настроек с «горкой» хватит для разработки проектов локально, не только мелких, но и довольно крупных. В следующих статьях опишу отдельно каждые использованные директивы (именно так называются строки, например server_name) этого файла.

Смотрите комментарии прям в конфигурационном файле.

Сохраняем файл. Теперь нам надо проверить, нет ли в нем ошибок. Сделать мы это можем командой.

Если видим такую информацию как на скриншоте, значит у нас все верно, может продолжать настройку. Если вы получаете какие-либо ошибки, стоит перепроверить конфигурационный файл.

Теперь нам надо активировать конфигурационный файл, в каталоге /etc/nginx/sites-enabled/ необходимо создать симлинк (символическая ссылка). Если у вас nginx был установлен «с нуля», то в этом каталоге есть симлинк на файл default, про который рассказывалось выше, его можно удалить, если он вам не требуется. Переходим в нужный каталог.

Теперь мы в нужном каталоге. Давайте создадим наш симлинк. Для создания используется команда ln с флагом -s, далее мы укажем путь до нашего конфига project.local.

Посмотрим на наш созданный симлинк.

Чтобы убедиться что мы делаем еще все верно опять запустим команду.

Если все ок, едем дальше.

Файл hosts

Этот файл находится по пути /etc/hosts. Наличие в нем записей, позволяет запускать nginx с использованием в качестве домена localhost. В этом файле можно присваивать альтернативные псевдонимы, например для нашего проекта project.local, мы присвоим домен project.local.

Открываем файл в редакторе nano.

У вас в этом файле будет и другая информация, просто игнорируйте ее. Вам всего лишь нужно добавить строку как на моем скриншоте.

Не забываем сохранить файл. На этом настройка файла hosts закончена.

Установка php-fpm (>=7.0)

Проверяем установленную версию, на всякий случай, хотя в Ubuntu 16.04.1 в репозиториях лежит именно 7.0 версия.

Убеждаемся что все ок. Стартуем php-fpm.

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

Теперь пойдем для в каталог с нашим проектом, у меня он лежит по такому пути.

Поднимемся на каталог выше и сделаем права 777 (то есть мы будем делать полные права каталогу с нашим проектом project.local). В будущем это избавим нас от лишних проблем.

На этом настройка ПО завершена, давайте создадим тестовый файл в нашем рабочем каталоге project.local и убедимся что все работает. Я создам файл index.php с таким содержанием.

Идем в браузер и видим что у нас все прекрасно работает! Интерпретатор php в том числе.

С помощью systemctl restart на PHP-FPM не создает требуемый сокет в /var/run/php/ , но перезагрузка делает.

Как я могу настроить мои настройки, чтобы разрешить перезапуск службы без перезагрузки?

обзор

Я собираю несколько экземпляров PHP-FPM из исходного кода на одном сервере (без контейнеров) для использования с веб-приложениями разного возраста. Я успешно настроил PHP 7.1, PHP 7.2 и PHP 7.3 вместе. Все они запускаются правильно при загрузке, все они имеют сокет в /var/run/php/ они все отвечают, как и ожидалось от браузера.

Содержание /var/run/php после загрузки

Кажется, что каждая служба работает без проблем. Вот systemctl status вывод для каждого:

PHP 7.1 после загрузки

PHP 7.2 после загрузки

PHP 7.3 после загрузки

Если я внесу изменения в соответствующие php.ini файл, это гарантирует перезапуск службы для обработки изменений. В моем случае, когда я перезапускаю сервис, используя systemctl restart (например sudo systemctl restart php7.1-fpm ), сервис, кажется, перезапускается изящно, но все сокеты PHP удаляются - независимо от версии, которую я перезапускаю.

Там нет вывода консоли после systemctl restart и когда я проверяю systemctl status на перезапущенном сервисе (например, PHP 7.1 в предыдущем абзаце) сервис работает:

PHP 7.1 после systemctl restart

Обратите внимание на разницу во времени Active , Если я запрашиваю другие службы таким же образом (примечание: они не были перезапущены мной), метки времени будут от начального запуска при загрузке:

PHP 7.2 после systemctl restart на PHP 7.1

PHP 7.3 после systemctl restart на PHP 7.1

. и все же все розетки отсутствуют:

Содержание /var/run/php после systemctl restart на PHP 7.1

У меня такое ощущение, что я что-то испортил в .service файл без понимания. Пока я занимался поиском и устранением неисправностей, я заметил, что использую разные каталоги для PID и сокета. PID не создается во время загрузки, так как /run/php-fpm/ не существует. У меня есть смутное воспоминание о том, что мне не рекомендуется хранить сокеты и PID в одном каталоге, но я не могу вспомнить точные детали.

PHP 7.1 .service файл

Заранее спасибо за любые указатели или дальнейшее чтение.

1 ответ

При дальнейшем расследовании выясняется, что мне не хватало RuntimeDirectoryPreserve Директива в моем файле модуля. Когда служба была остановлена, RuntimeDirectory был удален… вместе с розетками.

Интерпретатор языка программирования PHP может работать в нескольких режимах. Он может быть интегрирован в веб-сервер в виде специального модуля или использоваться как отдельный сервис php-fpm. Аббревиатура FPM расшифровывается как Fastcgi Process Manager. Это сервис, который запускает несколько процессов, которые могут выполнять PHP скрипты. Процессы могут получить скрипты, которые надо выполнить по TCP или Unix сокетам.

Обычно php-fpm используется вместе с веб-сервером Nginx. В этой статье мы рассмотрим как выполняется настройка PHP-FPM для максимально эффективной работы на вашем сервере.

Настройка PHP-FPM

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

1. Установка компонентов

Сервис php-fpm поставляется вместе с интерпретатором php. Установка php-fpm Ubuntu выполняется такой командой:

sudo apt install php-fpm

Кроме того нам понадобится веб-сервер Nginx, потому что php-fpm чаще всего используется вместе с этим веб-сервером:

sudo apt install nginx

2. Конфигурационные файлы

В этой инструкции мы будем рассматривать настройку PHP-FPM на примере Ubuntu. Основной конфигурационный файл находится в такому пути:

Обратите внимание, что это не php.ini файл, а файл настройки именно FPM процессов. Файл php.ini находится в этой же папке:

Вы можете использовать его в своей конфигурации или копировать для создания новых пулов.

3. Создание пула

Теперь откройте этот файл в текстовом редакторе, например в vim:

sudo vi /etc/php/7.4/fpm/pool.d/losst.conf

Первым делом вам нужно выбрать имя пула в квадратных скобках в самой верхней части файла, например, losst, это имя можно использовать в конфигурации с помощью переменной $pool, а ещё оно будет отображаться в менеджере процессов:

Далее надо изменить группу и пользователя, от имени которых будут запускаться процессы пула. Это важно, поскольку у процесса должен быть доступ к файлам PHP, которые надо выполнить. Обычно в Ubuntu для таких целей используется пользователь и группа www-data. От имени этого же пользователя обычно запускается веб-сервер:

Обычно, если вы получаете ошибку permission denied при интерпретации php файлов в php-fpm, означает, что процесс php-fpm запущен от имени не того пользователя или включена строгая политика SELinux.

4. Настройка сокета

Дальше нужно настроить каким образом Nginx или другой веб-сервер будет обращаться к PHP-FPM. Как я уже говорил выше, можно настроить ожидание соединений на TCP порту. Обычно используются порты 9000, 9001, 9002 и так далее. В данном случае надо передать IP адрес на котором следует слушать и порт. Лучше использовать локальный IP адрес 127.0.0.1, чтобы к сервису никто не мог подключится из интернета. Второй вариант - использовать файловый Unix сокет, тогда надо просто передать путь к файлу сокета. В данном примере используется сетевой сокет 127.0.0.1:9000. Вид сокета не имеет значения, но сетевой использовать удобнее:

Если вы используйте файловый сокет, к нему должен быть доступ у веб-сервера, поэтому надо сделать владельцами файла того пользователя и группу, от имени которых запущен веб-сервер, в данном случае www-data и дать им все права на него:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Если сокет сетевой, то в этом нет необходимости. Для сетевого сокета можно дополнительно указать с каких адресов можно к нему подключаться. Например, только от 127.0.0.1:

5. Настройка процессов

С помощью параметра pm можно настроить сколько дочерних процессов будет запускаться для этого пула и когда. Есть три режима работы:

dynamic - процессы создаются в зависимости от нагрузки и настроек, если нагрузки нет, всё равно работает определённое количество процессов;
ondemand - процессы создаются как только возникает нагрузка;
static - количество процессов всегда одинаковое, указанное в настройках.

Режим static не выгоден, потому что вне зависимости от нагрузки потребляется много памяти и процессорного времени на поддержание работы процессов. Более интересны режимы ondemand и dynamic. Давайте будем использовать режим dynamic. Этот режим имеет три настройки:

pm.max_children - очень важный параметр, который работает для всех трёх режимов, означает максимально возможное количество дочерних процессов, если значение будет слишком маленьким, то при возрастании нагрузки, лимит исчерпается и ваш сайт начнёт тупить, если слишком большим - исчерпается оперативная память и что-то упадёт;
pm.start_servers - указывает сколько процессов запускать при старте сервиса;
pm.min_spare_servers - минимальное количество процессов в режиме ожидания (ничего не обрабатывающих), если количество процессов меньше, будет создан ещё один;
pm.max_spare_server - максимальное количество процессов в режиме ожидания, если количество процессов будет больше, лишние будут завершены;

Для режима static надо указать только pm.max_children. Для режима ondemand кроме pm.max_children надо указать pm.process_idle_timeout этот параметр означает через какой промежуток времени простоя процесс будет завершен.

Давайте разберемся с режимом dynamic. Запускать много дочерних процессов при старте не надо, в большинстве случаев 2-3 будет достаточно:

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

Максимальное количество процессов определяет как быстро процессы будут завершаться при падении нагрузки, можно оставить 10 процессов:

Параметр pm.max_children настройте под себя, обычно достаточно 20-30 процессов, но всё зависит от нагрузки и количества оперативной памяти, если памяти мало лучше пожертвовать производительностью и установить меньшее значение:

Почти готово. Но есть ещё одна проблема. Если дочерние процессы работают слишком долго, в них накапливаются утечки памяти, и рано или поздно на сервере память закончится. Чтобы этого избежать можно настроить автоматическое завершение процесса после выполнения определённого количества запросов, например, 1000:

6. Настройка статистики

Для подбора оптимального значения pm.max_children вам может понадобиться посмотреть статистику в реальном времени сколько процессов запущено, сколько из них находится в ожидании, а также какая длина очереди ожидающих выполнения запросов. Для включения вывода статистики просто добавьте такую строчку:

7. Настройка php.ini

Несмотря на то, что есть общий файл php.ini для всех пулов, вы можете менять настройки прямо в файле пула, для этого используются директивы php_admin_value и php_admin_flag. Первая используется для установки строковых значений, а вторая - для флагов. У директив есть альтернативы: php_value и php_flag, они отличаются только тем, что их можно перезаписать с помощью функции ini_set, а значения заданные с помощью директив с приставкой admin перезаписать нельзя.

php_admin_flag[display_errors] = off
php_admin_value[error_log] = /var/log/fpm-php.losst.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 32M

Когда все настройки завершены, не забудьте сохранить изменения и перезапустить php-fpm:

sudo systemctl restart php7.4-fpm

8. Настройка веб-сервера

Для того чтобы всё протестировать придётся настроить ещё и веб-сервер. В конфигурационный файл виртуального хоста Nginx надо добавить такие строки:

location /status fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
>
location

\.php$ fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) return 404;
>
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
>

Первая секция позволяет смотреть статистику работы php-fpm открыв в браузере ссылку /status, которую мы ранее указали в настройках. Вторая секция обрабатывает всё остальные файлы php. Первая строка второй секции разбивает путь к скрипту по регулярному выражению на две части: $fastcgi_script_name и $fastcgi_path. Первая переменная нам понадобится в следующей же строчке, где с помощью условия проверяется существует ли такой файл, и если нет, то возвращается 404.

Дальше надо импортировать файл fastcgi_params, в котором передаются все переменные, которые потом будут доступны в массиве $_SERVER из скрипта. В следующей строчке объявляется ещё один важный параметр, которого нет в fastcgi_params, потому что он использует переменную $fastcgi_script_name, полученную ранее. Именно по нему php-fpm определяет путь к скрипту, который надо выполнить, если его не передать, вы получите пустой экран.

Последняя директива fastcgi_pass указывает как надо передавать данные php-fpm, сюда можно передать путь к файлу сокету, на котором слушает сервис или IP адрес и порт. В данном случае используется ранее настроенный 127.0.0.1:9000. После завершения настройки перезапустите Nginx:

sudo systemctl restart nginx

Теперь вы можете открыть в браузере страницу статистики, как видите всё работает:

Можно ещё создать файл phpinfo.php с текстом <?php phpinfo(); ?> в каталоге веб-сервера и посмотреть настройки php, например, memory_limit, заданный в файле конфигурации пула работает:

Настройка веб-сервера может очень сильно отличаться в зависимости от ваших требований. Здесь приведен только общий пример, чтобы проверить работоспособность и верность настройки.

Выводы

В этой небольшой статье мы рассмотрели как выполняется настройка PHP-FPM с Nginx для оптимальной обработки PHP скриптов на сайте. Как видите, несмотря на довольно сложную архитектуру, с программой вполне можно разобраться. Подобрав верное значение pm.max_children вы сможете обеспечить максимальную производительность вашему сайту и предотвратить потребление всей оперативной памяти.

Нет похожих записей

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