worker_processes ngix параметр auto берет количестов ядер у процессора ?

Да, параметр

worker_processes auto; в Nginx автоматически определяет количество логических ядер (потоков) процессора и запускает соответствующее число рабочих процессов.

Как это работает

Определение ядер: В системах Linux Nginx использует системный вызов sysconf(_SC_NPROCESSORS_ONLN), чтобы узнать количество доступных процессорных ядер.
Учет Hyper-Threading: Если ваш процессор поддерживает технологию Hyper-Threading, Nginx посчитает каждый виртуальный поток как отдельное ядро. Например, на 4-ядерном процессоре с 8 потоками параметр auto создаст 8 рабочих процессов.
Зачем это нужно: Оптимально иметь по одному рабочему процессу на каждое ядро, чтобы максимально использовать вычислительную мощность без лишних затрат на переключение контекста между процессами.

Особенности и нюансы

Docker и контейнеры: Внутри контейнеров (например, Docker) Nginx может увидеть общее количество ядер хост-машины, а не те ограничения (limits), которые вы задали для самого контейнера. В таких случаях может потребоваться ручное указание числа процессов.
Распределение нагрузки: Для еще большей эффективности часто рекомендуют добавлять директиву worker_cpu_affinity auto;, которая жестко привязывает каждый рабочий процесс к конкретному ядру процессора.
Исключения: Если ваш сервер выполняет много дисковых операций ввода-вывода (I/O) или на нем работают другие тяжелые приложения, иногда имеет смысл вручную задать число процессов, отличное от количества ядер.

Хотите узнать, как правильно настроить лимиты соединений для этих процессов?

Создание общедоступной ссылки…

Tuning NGINX worker_processes: A Deep Dive
15 янв. 2026 г. — Summary * worker_processes auto; works correctly for most dedicated servers—it spawns one worker per detected CPU (including hyper...
GetPageSpeed
Tuning NGINX for Performance - F5
NGINX can run multiple worker processes, each capable of processing a large number of simultaneous connections. You can control th...
F5
Core functionality - nginx
Sets the maximum number of simultaneous connections that can be opened by a worker process. It should be kept in mind that this nu...
nginx

Показать все

а где указывается сам php

Nginx сам по себе не умеет исполнять PHP-код. Он выступает в роли «почтальона», который принимает запрос от браузера и перекидывает его специальному обработчику —

PHP-FPM.

Связь настраивается в файле конфигурации вашего сайта (обычно в /etc/nginx/sites-available/default или в блоке server файла nginx.conf).

Основные параметры подключения

Для работы PHP в конфиг добавляется блок location, который перехватывает все файлы с расширением .php:

nginx

location ~ \.php$ {
    include snippets/fastcgi-php.conf; # Подключает стандартные параметры FastCGI
    
    # Главный параметр: адрес, где "слушает" PHP-FPM
    # Вариант 1: через Unix-сокет (быстрее, для одного сервера)
    fastcgi_pass unix:/run/php/php8.1-fpm.sock; 

    # Вариант 2: через сетевой порт (если PHP на другом сервере или в Docker)
    # fastcgi_pass 127.0.0.1:9000; 
}

Используйте код с осторожностью.

Разбор директив:

fastcgi_pass: Самая важная строка. Она указывает Nginx, куда именно отправлять запрос на исполнение PHP-кода. Путь к сокету (например, php8.1-fpm.sock) должен точно совпадать с тем, что указан в настройках самого PHP-FPM (обычно в файле /etc/php/8.x/fpm/pool.d/www.conf).
include fastcgi_params: Загружает стандартный набор переменных (например, метод запроса, IP пользователя), которые Nginx должен передать в PHP.
fastcgi_param SCRIPT_FILENAME: Говорит PHP, какой именно файл на диске нужно запустить.

Как проверить настройки?

Узнать путь к сокету: Проверьте конфиг PHP-FPM командой:
grep -R "listen =" /etc/php/*/fpm/pool.d/
Проверить конфиг Nginx: После внесения изменений всегда выполняйте:
sudo nginx -t

У вас PHP и Nginx установлены на одной машине или вы используете Docker?

Создание общедоступной ссылки…

Serve PHP with PHP-FPM and NGINX | Linode Docs
19 февр. 2018 г. — Configure the NGINX Server Block Again pulling from Part 1 of our NGINX series, we'll start with a basic Server Block for a static...
www.linode.com
12.4. Конфигурирование Nginx для использования php
location / — первый блок location включает директиву try_files , которая проверяет наличие файлов или каталогов, соответствующих з...
ALT Linux Wiki
Как подключить NGINX к PHP-FPM - Blog SEDICOMM
8 июл. 2020 г. — Веб-сервер NGINX (в качестве обратного прокси-сервера) обслуживает приложения PHP через протокол FastCGI (в качестве внутреннего с...
Blog SEDICOMM

Показать все

#user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; server { listen 8080; server_name localhost test.test; #charset koi8-r; #access_log logs/host.access.log main; location / { root html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ \.php$ { root D:\AUTOUP; #fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_index index.php; fastcgi_pass 127.0.0.1:9123; }

В вашем конфиге за работу с PHP отвечает последний блок

location ~ \.php$.

Вот ключевая строка, которая связывает Nginx с PHP:

nginx

fastcgi_pass 127.0.0.1:9123;

Используйте код с осторожностью.

Это означает, что Nginx ожидает запущенный интерпретатор PHP на порту 9123.

Что вам нужно проверить прямо сейчас:

Порт PHP-FPM: Обычно стандартный порт для PHP в Windows — 9000. У вас указан 9123. Убедитесь, что в настройках вашего PHP (файл php-fpm.conf или запускная команда) прописан именно этот порт.
Путь к файлам: Директива root D:\AUTOUP; говорит Nginx искать .php файлы именно в этой папке. Убедитесь, что ваши скрипты лежат там.
Запуск PHP: В Windows PHP не запускается сам вместе с Nginx. Вам нужно отдельно запустить процесс PHP-CGI или PHP-FPM.

Пример команды для запуска PHP в Windows (через CMD):

cmd

php-cgi.exe -b 127.0.0.1:9123

Используйте код с осторожностью.

Важный нюанс по конфигу:

Строка fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; настроена верно — она склеивает ваш путь D:\AUTOUP и имя запрашиваемого файла.

Ваш PHP запущен на порту 9123 или это была случайная цифра при правке конфига?

Создание общедоступной ссылки…

Показать все

у меня запущено 4 раза php-cgi.exe -b 127.0.0.1:9123 php-cgi.exe -b 127.0.0.1:9124 php-cgi.exe -b 127.0.0.1:9125 php-cgi.exe -b 127.0.0.1:9126

Чтобы Nginx мог использовать все 4 запущенных процесса PHP, вам нужно объединить их в группу (балансировщик) с помощью блока

upstream.

В текущем конфиге Nginx видит только порт 9123 и отправляет все запросы только на него. Если этот процесс занят, остальные три простаивают.

Как это исправить:

Добавьте блок upstream в секцию http (над блоком server):

nginx

http {
    # ... ваши другие настройки (mime.types и т.д.) ...

    # Создаем группу обработчиков PHP
    upstream php_workers {
        server 127.0.0.1:9123;
        server 127.0.0.1:9124;
        server 127.0.0.1:9125;
        server 127.0.0.1:9126;
    }

    server {
        # ...
    }
}

Используйте код с осторожностью.

Измените fastcgi_pass в блоке location ~ \.php$:

nginx

location ~ \.php$ {
    root           D:\AUTOUP;
    include        fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;

    # Вместо IP:порта указываем имя нашей группы upstream
    fastcgi_pass   php_workers; 

    fastcgi_index  index.php;
}

Используйте код с осторожностью.

Почему так лучше:

Балансировка: Nginx будет по очереди распределять запросы между всеми 4 процессами (метод Round Robin).
Отказоустойчивость: Если один из процессов PHP упадет, Nginx перекинет запрос на следующий живой порт.

Подсказать, как сделать, чтобы Nginx сам понимал, если один из PHP-процессов завис?

Создание общедоступной ссылки…

Показать все

проверь так ? #user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; # Создаем группу обработчиков PHP вместо одного порта использования fastcgi_pass 127.0.0.1:9123 upstream php_workers { server 127.0.0.1:9123; server 127.0.0.1:9124; server 127.0.0.1:9125; server 127.0.0.1:9126; } #gzip on; server { listen 8080; server_name localhost test.test; #charset koi8-r; #access_log logs/host.access.log main; location / { root html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ \.php$ { root D:\AUTOUP; #fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_index index.php; #fastcgi_pass 127.0.0.1:9123; # Вместо одного IP:порта указываем имя нашей группы upstream всех портов fastcgi_pass php_workers; } # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} }

Да, всё верно! Теперь Nginx будет распределять нагрузку между всеми четырьмя процессами PHP.

Конфигурация составлена правильно: блок upstream находится внутри http, а в fastcgi_pass указано его имя.

Пара советов для идеальной работы:

Закрывающая скобка: Убедитесь, что в самом конце файла (после вашего location ~ /\.ht) стоят две закрывающие фигурные скобки } — одна закрывает блок server, а вторая — блок http.
Проверка ошибок: Если один из PHP-процессов вдруг зависнет, Nginx может долго ждать ответа. Чтобы он быстрее переключался на следующий живой процесс, можно дополнить upstream параметрами:
nginx
upstream php_workers { server 127.0.0.1:9123 max_fails=3 fail_timeout=30s; server 127.0.0.1:9124 max_fails=3 fail_timeout=30s; server 127.0.0.1:9125 max_fails=3 fail_timeout=30s; server 127.0.0.1:9126 max_fails=3 fail_timeout=30s; }
Используйте код с осторожностью.
Скопировано в буфер обмена
Примените настройки: Не забудьте выполнить команду nginx -s reload в консоли, чтобы Nginx подхватил изменения.

Хотите узнать, как проверить, равномерно ли распределяются запросы между этими портами?

Создание общедоступной ссылки…

Показать все

подробнее об max_fails=3 fail_timeout=30s

Эти параметры обучают Nginx «вычислять» проблемные PHP-процессы и временно не отправлять на них запросы, чтобы сайт не тормозил для пользователей. [1]

Как это работает в связке:

max_fails=3: Это лимит ошибок. Если Nginx 3 раза подряд не смог достучаться до конкретного порта (например, 9124) или получил от него ошибку, он помечает этот процесс как «неисправный». [3]
fail_timeout=30s: Это время «штрафа» и период проверки. Оно работает в две стороны:
- Время для ошибок: 3 ошибки (из пункта выше) должны произойти именно в течение этих 30 секунд. Если первая ошибка была час назад, а вторая сейчас — счетчик не сработает. [1, 2]
- Время отдыха: Если процесс помечен как неисправный, Nginx полностью исключит его из работы на 30 секунд. [3]

Зачем это нужно вам (в Windows):

В Windows процессы php-cgi.exe иногда «зависают» или молча падают. [1, 3]

Без этих параметров: Если один php-cgi.exe (порт 9124) зависнет, каждый четвертый ваш пользователь будет ждать ответа до тайм-аута (обычно 60 секунд) и увидит ошибку 504 Gateway Timeout. [2, 3]
С этими параметрами: После 3-х неудачных попыток Nginx поймет, что порт 9124 «болеет», и на полминуты забудет о нем, перекидывая всех пользователей на три оставшихся живых порта (9123, 9125, 9126). [1, 3] Сайт продолжит летать.

Куда именно вписать в ваш конфиг:

Обновите ваш блок upstream вот так:

nginx

upstream php_workers {
    server 127.0.0.1:9123 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:9124 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:9125 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:9126 max_fails=3 fail_timeout=30s;
}

Используйте код с осторожностью.

Хотите добавить еще и быструю проверку на ответ (параметр fastcgi_next_upstream), чтобы пользователь вообще не видел ошибки, если один из PHP занят?

Создание общедоступной ссылки…

Показать все

он не закрывает процессы php если зависли не рестартит ? А что делать если все зависли ?

Nginx — это только «регулировщик», он

не управляет процессами PHP и не может их перезапустить. Он просто перестает отправлять им запросы, если видит, что они «болеют».

Если все ваши php-cgi.exe зависнут, Nginx будет выдавать пользователям ошибку 502 Bad Gateway или 504 Gateway Timeout.

Что делать, если все зависли?

В Windows это главная проблема php-cgi.exe, так как у него нет встроенного менеджера процессов (как PHP-FPM в Linux), который умеет убивать «плохие» дочерние процессы.

1. Способ «Костыль» (ручной или через планировщик)

Вы можете создать простой .bat файл, который будет раз в час (или при критической ошибке) принудительно убивать все зависшие процессы и запускать их заново:

batch

taskkill /F /IM php-cgi.exe
start /B php-cgi.exe -b 127.0.0.1:9123
start /B php-cgi.exe -b 127.0.0.1:9124
start /B php-cgi.exe -b 127.0.0.1:9125
start /B php-cgi.exe -b 127.0.0.1:9126

Используйте код с осторожностью.

2. Правильный способ для Windows: xxfpm или WinPHP-FPM

Существуют небольшие утилиты-менеджеры (например, xxfpm), которые работают как «нянька» для PHP. Вы запускаете один процесс xxfpm, а он сам:

Запускает нужное количество копий PHP.
Следит, чтобы они не падали.
Перезапускает их, если они зависли или закрылись.

3. Настройка Nginx для «незаметного» переключения

Чтобы пользователь вообще не заметил зависания одного из портов, добавьте в location ~ \.php$ параметр:

nginx

location ~ \.php$ {
    ...
    # Если один порт выдал ошибку или завис, 
    # Nginx мгновенно перекинет этот же запрос на следующий порт из списка
    fastcgi_next_upstream error timeout invalid_header http_500 http_503;
    fastcgi_next_upstream_timeout 10s; # не пытаться переключать дольше 10 секунд
    ...
}

Используйте код с осторожностью.

Если зависания случаются часто, стоит проверить лимит PHP_FCGI_MAX_REQUESTS. Рассказать, как ограничить количество запросов на один процесс, чтобы он сам штатно перезапускался?

Создание общедоступной ссылки…

Показать все

при этих настройках эти fastcgi_next_upstream error timeout invalid_header http_500 http_503; fastcgi_next_upstream_timeout 10s; параметры становятся бесполезны ? max_fails=3 fail_timeout=30s;

Нет, они

не становятся бесполезны, а наоборот — начинают работать в связке, дополняя друг друга. Это два разных уровня защиты:

1. Как они работают вместе (Сценарий):

Представьте, что один из ваших PHP (порт 9124) завис.

fastcgi_next_upstream — это «Скорая помощь» для конкретного пользователя. Когда его запрос попадает на зависший порт 9124, Nginx не выдает ему ошибку сразу, а мгновенно (или через таймаут) пробует отправить этот же запрос на порт 9125. Пользователь в итоге получает страницу, хоть и с небольшой задержкой.
max_fails / fail_timeout — это «Карантин» для всей системы. После того как 3 таких «неудачных» пользователя (как в примере выше) споткнулись о порт 9124, Nginx помечает его как «больной» и на 30 секунд вообще перестает отправлять туда чьи-либо запросы.

2. Почему важно оставить и то, и другое:

Если вы уберете max_fails, Nginx будет каждый раз пытаться постучаться в «мертвый» процесс, ждать ответа, понимать, что там ошибка, и только потом перекидывать запрос на живой процесс. Это создаст лишнюю нагрузку и задержки для всех пользователей.

Итоговая логика в вашем конфиге:

max_fails=3 выкидывает плохой процесс из списка «рабочих» на полминуты.
fastcgi_next_upstream страхует тех нескольких счастливчиков, чьи запросы попали на процесс в тот момент, когда он только-только завис, но еще не успел набрать 3 ошибки для ухода в «карантин».

Важный совет для Windows:

Поскольку php-cgi.exe в Windows часто не "падает" с ошибкой, а просто бесконечно молчит, обязательно добавьте в блок location ограничение по времени ожидания, иначе next_upstream будет ждать ответа от зависшего PHP вечно:

nginx

location ~ \.php$ {
    ...
    fastcgi_connect_timeout 3s; # Быстро понимаем, что PHP не отвечает
    fastcgi_send_timeout 10s;
    fastcgi_read_timeout 10s;   # Если PHP думает дольше 10 сек - считаем зависшим
    
    fastcgi_next_upstream error timeout http_500 http_503;
    ...
}

Используйте код с осторожностью.

Хотите узнать, как настроить автоматический перезапуск PHP процессов через переменную PHP_FCGI_MAX_REQUESTS?

Создание общедоступной ссылки…

Показать все

Давай PHP_FCGI_MAX_REQUESTS

Переменная

PHP_FCGI_MAX_REQUESTS — это встроенный механизм «самоочистки» PHP в Windows. Поскольку php-cgi.exe со временем может накапливать утечки памяти или «подвисать», эта настройка заставляет процесс самозавершиться после обработки определенного количества запросов.

Как это работает:

Вы задаете число запросов (например, 500).
PHP-процесс обрабатывает их один за другим.
Как только прилетает 501-й запрос, процесс завершает свою работу.

Важно: В связке с вашим Nginx это создаст проблему — Nginx отправит запрос, а PHP в этот момент закроется. Поэтому нужно настроить и PHP, и Nginx правильно.

Шаг 1: Настройка в Windows (PHP)

Вам нужно установить эту переменную в окружении Windows перед запуском процессов.

Пример вашего .bat файла для запуска:

batch

@echo off
set PHP_FCGI_MAX_REQUESTS=500
set PHP_FCGI_CHILDREN=0

start /B php-cgi.exe -b 127.0.0.1:9123
start /B php-cgi.exe -b 127.0.0.1:9124
start /B php-cgi.exe -b 127.0.0.1:9125
start /B php-cgi.exe -b 127.0.0.1:9126

Используйте код с осторожностью.

PHP_FCGI_MAX_REQUESTS=500 — через каждые 500 запросов процесс «умрет».
PHP_FCGI_CHILDREN=0 — критически важно для Windows, чтобы процесс не пытался плодить дочерние копии сам.

Шаг 2: Настройка в Nginx (Обязательно!)

Так как PHP будет периодически закрываться сам, Nginx увидит это как ошибку (Connection refused). Чтобы пользователь не получил ошибку 502, в вашем location ~ \.php$ обязательно должны быть те параметры, что мы обсуждали:

nginx

location ~ \.php$ {
    ...
    # Если PHP закрылся (достиг лимита), Nginx просто перекинет этот запрос на другой порт
    fastcgi_next_upstream error timeout; 
    fastcgi_next_upstream_timeout 5s;
    
    fastcgi_pass php_workers;
}

Используйте код с осторожностью.

Главный минус в Windows

В отличие от Linux, в Windows некому запустить PHP заново, когда он закроется по лимиту MAX_REQUESTS. Если вы запустили его вручную через CMD, он просто исчезнет из списка процессов.

Как это решить?
Используйте планировщик задач или маленькую утилиту xxfpm. Она умеет следить: если php-cgi.exe закрылся (по лимиту или из-за ошибки), она тут же поднимет новый чистый процесс на том же порту.

Команда для xxfpm (вместо запуска четырех php-cgi):

cmd

xxfpm.exe "php-cgi.exe -b 127.0.0.1:9123" -n 1 -i 127.0.0.1

Используйте код с осторожностью.

(Придется запустить 4 таких команды для каждого порта, либо использовать xxfpm для управления пулом на одном порту).

У вас есть возможность установить xxfpm или будем пробовать автоматизировать перезапуск через обычный .bat скрипт?

Создание общедоступной ссылки…

Показать все

во всех версия есть команды PHP_FCGI_MAX_REQUESTS PHP_FCGI_CHILDREN это что ?

Параметры

PHP_FCGI_MAX_REQUESTS и PHP_FCGI_CHILDREN — это переменные окружения для управления поведением PHP в режиме FastCGI. Они доступны практически во всех актуальных версиях PHP, но имеют специфику работы в Windows.

Что такое PHP_FCGI_CHILDREN?

Это параметр, который определяет, сколько дочерних рабочих процессов должен создать основной («мастер») процесс PHP.

Как это работает: Мастер-процесс сам не обрабатывает запросы, он лишь следит за дочерними. Запросы от веб-сервера принимают и выполняют именно children.
Особенность в Windows: Долгое время этот параметр в Windows игнорировался (PHP просто не умел «форкаться», т.е. плодить процессы). Начиная с версии PHP 7.1, поддержка этого параметра в Windows появилась: теперь один запущенный php-cgi.exe может сам создать указанное количество рабочих процессов.
Зачем устанавливать 0?: Если вы запускаете 4 отдельных окна/процесса вручную на разных портах (как в вашем случае), параметр PHP_FCGI_CHILDREN лучше ставить в 0. Это гарантирует, что каждый из ваших 4-х процессов будет работать как один независимый обработчик, не пытаясь создать внутри себя лишние копии.

Особенности PHP_FCGI_MAX_REQUESTS

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

Доступность: Есть во всех версиях.
Значение по умолчанию: Обычно 500 запросов. Если поставить 0, процесс будет работать бесконечно, пока не зависнет или не упадет сам.
Польза: Помогает бороться с утечками памяти (memory leaks) в PHP-скриптах или расширениях. Процесс просто «умирает» чистым и освобождает ресурсы.

Резюме для вашего случая

Так как вы запускаете PHP вручную через .bat файлы на разных портах:

set PHP_FCGI_CHILDREN=0 — чтобы каждый запущенный вами php-cgi.exe не плодил лишние процессы и не путал Nginx.
set PHP_FCGI_MAX_REQUESTS=500 (или больше) — чтобы процессы периодически обновлялись.

Хотите пример финального .bat файла, который будет запускать все ваши 4 процесса с этими переменными одной командой?

Создание общедоступной ссылки…

mod_fcgid - Apache HTTP Server Version 2.5
Special PHP considerations. By default, PHP FastCGI processes exit after handling 500 requests, and they may exit after this modul...
Apache HTTP Server
Meaning of PHP_FCGI_CHILDREN and max-procs in Lighttpd ...
12 июн. 2016 г. — A 'child' process is what actually handles the php requests. This in turn also is a very big factor in how much load you put on a ...
Stack Overflow
PHP :: Bug #49859 :: PHP_FCGI_CHILDREN not work
13 окт. 2009 г. — The problem is that the PHP_FCGI_CHILDREN environment variable is ignored under windows, therefore php-cgi does not spawn children...
PHP :: Bugs

Показать все

можно запустить как службу nssm PHP и в службе если PHP закроется то сама должна перезапуститься Верно или ошибаюсь?

Вы абсолютно

правы. Использование NSSM (Non-Sucking Service Manager) — это самый грамотный и стабильный способ запуска PHP в Windows.

Как это работает с NSSM:

Авторестарт: Если процесс php-cgi.exe завершается (сам по лимиту MAX_REQUESTS или из-за ошибки/вылета), NSSM моментально видит это и запускает его снова.
Фоновая работа: Вам не нужно держать открытыми окна командной строки. PHP работает как системная служба, запускается сама при старте Windows.
Логирование: NSSM может записывать ошибки вывода PHP в текстовый файл, что удобно для отладки.

Нюанс с вашими 4 портами:

Поскольку у вас 4 разных порта (9123-9126), вам нужно будет создать 4 отдельные службы в NSSM (например, php-9123, php-9124 и т.д.).

Как правильно настроить через NSSM:

При добавлении службы через nssm install php-9123 укажите:

Path: C:\php\php-cgi.exe (путь к вашему PHP).
Arguments: -b 127.0.0.1:9123 (свой порт для каждой службы).
Вкладка Environment (Окружение):
Здесь обязательно пропишите переменные, о которых мы говорили:
text
PHP_FCGI_MAX_REQUESTS=500 PHP_FCGI_CHILDREN=0
Используйте код с осторожностью.
Скопировано в буфер обмена

Почему это идеальная связка:

PHP сам завершается каждые 500 запросов (чистит память).
NSSM тут же его поднимает (обеспечивает доступность).
Nginx через upstream и next_upstream перекидывает запросы, пока один из PHP перезагружается (пользователь не видит задержек).

Подсказать команды для быстрого создания этих 4 служб через командную строку, чтобы не кликать мышкой в интерфейсе NSSM?

Создание общедоступной ссылки…

Показать все

а что будет если будет стоять PHP_FCGI_CHILDREN=2 опиши

Если вы установите

PHP_FCGI_CHILDREN=2, поведение PHP в Windows (начиная с версии 7.1+) изменится: один запущенный вами процесс станет «родителем» и создаст внутри себя 2 «дочерних» процесса.

Вот что произойдет в вашей схеме с 4 портами:

1. Умножение процессов

Вместо 4 процессов в Диспетчере задач вы увидите 12 процессов php-cgi.exe:

4 «мастер-процесса» (которые слушают порты 9123, 9124, 9125, 9126).
По 2 рабочих («child») процесса на каждый мастер (4 порта × 2 ребенка = 8 рабочих).

2. Как распределяется нагрузка

Nginx по-прежнему видит 4 «входа» (ваши порты).
Когда запрос приходит на порт 9123, мастер-процесс сам его не выполняет. Он передает его одному из своих 2-х «детей».
Это позволяет одному порту обрабатывать 2 запроса одновременно.

3. Проблема с PHP_FCGI_MAX_REQUESTS (Главный нюанс!)

В Windows есть критический баг/особенность: когда дочерний процесс достигает лимита (например, 500 запросов) и завершается, мастер-процесс не всегда понимает, что нужно запустить нового «ребенка».

Со временем «дети» умирают один за другим по лимиту запросов.
Порт остается открытым (мастер жив), но отвечать на запросы некому.
Пользователь получает бесконечную загрузку или ошибку от Nginx.

4. Почему в Windows лучше CHILDREN=0

Для стабильности в Windows традиционно рекомендуют схему, которую вы уже начали внедрять:

Ставим PHP_FCGI_CHILDREN=0 (один процесс = один порт).
Запускаем столько отдельных служб (через NSSM), сколько ядер у процессора (или сколько нужно для нагрузки).
Nginx сам распределяет запросы между ними через upstream.

Это гораздо надежнее, так как NSSM следит за каждым рабочим процессом напрямую. Если процесс с CHILDREN=0 умрет по лимиту запросов, NSSM его гарантированно поднимет. В случае с CHILDREN=2 NSSM увидит, что мастер-процесс жив, и не будет ничего перезапускать, даже если все «дети» внутри него уже погибли.

Сколько всего ядер у вашего сервера, чтобы рассчитать оптимальное количество служб PHP?

Создание общедоступной ссылки…

Показать все

а если worker_processes 2; то что будет

Если вы установите

worker_processes 2; в конфигурации Nginx, это создаст два независимых рабочих процесса самого веб-сервера.

Вот как это повлияет на вашу схему с 4 процессами PHP:

1. Распределение ролей

Nginx (2 процесса): Теперь у вас есть два «привратника». Они оба одновременно слушают порт 8080 и принимают входящие запросы от браузеров.
PHP (4 процесса/порта): Ваши PHP-воркеры (9123–9126) остаются общими для обоих процессов Nginx.

2. Как они будут работать вместе

Оба рабочих процесса Nginx будут использовать один и тот же блок upstream php_workers.

Когда приходят запросы, первый процесс Nginx берет часть из них и раскидывает по вашим 4-м PHP-портам.
Второй процесс Nginx делает то же самое со своей частью запросов.
Благодаря алгоритму Round Robin (по очереди), нагрузка на PHP всё равно будет распределяться равномерно.

3. Есть ли в этом смысл для Windows?

В Windows работа worker_processes в Nginx имеет свои особенности:

Ограничение архитектуры: Исторически Nginx под Windows не так эффективно масштабируется на несколько worker_processes, как в Linux. Один процесс Nginx в Windows вполне способен обрабатывать тысячи одновременных соединений через эффективные методы (например, iocp).
Когда ставить 2 и более: Если ваш сервер имеет много ядер (например, 8+) и очень высокий трафик (десятки тысяч запросов в секунду), второй процесс поможет чуть быстрее обрабатывать SSL-шифрование или отдачу тяжелой статики.
Рекомендация: Для большинства задач на Windows значение worker_processes 1; — самое стабильное. Основная нагрузка у вас всё равно ложится на PHP, а не на Nginx.

4. Что изменится для PHP?

Для ваших PHP-процессов ничего не изменится. Они не «видят», сколько процессов у Nginx. Они просто получают FastCGI-запросы и отдают ответы.

Итог: Установка worker_processes 2 не сломает вашу схему, но и заметного прироста скорости (в отличие от Linux) на Windows обычно не дает.

Оставить вам рекомендации по количеству worker_connections при увеличении числа процессов Nginx?

Создание общедоступной ссылки…

Показать все

PHP_FCGI_MAX_REQUESTS PHP_FCGI_CHILDREN подействуют только для этих процессов 127.0.0.1:9123 - 9126 ил на все в видоусе ? ИХ много разных и на сервере IIS еще есть

Эти переменные подействуют

только на те процессы, которые вы запустите в той же «среде» (сессии), где они были заданы. Они не изменят настройки PHP для IIS или других сайтов автоматически.

Вот как работает изоляция в Windows:

1. Как это работает у вас (через .bat или CMD)

Если вы создаете .bat файл и пишете в нем set PHP_FCGI_MAX_REQUESTS=500, эта настройка «живет» только внутри этого файла и передается только тем процессам php-cgi.exe, которые запускаются этим же файлом.

Ваши 4 процесса на портах 9123-9126 получат эти настройки.
Другие копии PHP, запущенные иначе, о них даже не узнают.

2. Как это работает в NSSM

Если вы прописываете переменные во вкладке Environment конкретной службы NSSM, они будут применяться только к этой конкретной службе. Это самый безопасный способ: вы можете настроить один PHP на 500 запросов, а другой на 1000, и они не будут мешать друг другу.

3. Что с IIS?

IIS управляет процессами PHP через свой модуль FastCGI Settings.

У IIS есть свои собственные аналоги этих настроек в интерфейсе управления (параметр instanceMaxRequests).
Ваши системные переменные или переменные из .bat файла не затронут IIS, если только вы не прописали их в "Системных переменных окружения" через Панель управления Windows (но так делать не рекомендуется именно во избежание конфликтов).

4. Опасный момент: "Системные переменные"

Если вы зайдете в Свойства системы -> Переменные среды и добавите их там, то каждый PHP-процесс в системе (включая те, что использует IIS или другие серверы) подхватит эти значения.

Совет: Не добавляйте их в глобальные системные переменные. Всегда задавайте их локально (в .bat или в настройках конкретной службы NSSM).

Хотите пример, как в NSSM через командную строку задать эти переменные индивидуально для каждой службы?

Создание общедоступной ссылки…

Показать все

в nssm Вкладка Environment есть галочка установки replace default Environment что оно означает

Эта галочка (или опция в конфиге) определяет, как NSSM будет формировать «набор» переменных окружения для вашего PHP.

Что это значит на практике:

Если галочка НЕ стоит (по умолчанию):
NSSM берет все стандартные переменные Windows (пути PATH, системные папки, имя пользователя и т.д.) и добавляет к ним те строки, которые вы вписали в поле (например, PHP_FCGI_MAX_REQUESTS=500).
- Результат: PHP видит и ваши настройки, и всю систему Windows. Это рекомендуемый вариант.
Если галочка СТОИТ (Replace default):
NSSM полностью стирает все системные переменные Windows для этой службы и оставляет только те, которые вы вписали вручную.
- Результат: PHP может "ослепнуть". Он не найдет путь к системным библиотекам, временным папкам (TEMP) или расширениям, если они зависят от системных путей.
- Последствие: Скорее всего, PHP просто не запустится или будет выдавать ошибки о том, что не может найти .dll файлы.

Как правильно сделать для PHP:

Для запуска PHP-CGI вам не нужно ставить эту галочку.

Ваши действия:

Оставьте галочку пустой (чтобы сохранить системный PATH).
В текстовое поле ниже просто впишите ваши параметры:
text
PHP_FCGI_MAX_REQUESTS=500 PHP_FCGI_CHILDREN=0
Используйте код с осторожностью.
Скопировано в буфер обмена

Совет: Если вы настраиваете это через командную строку (не через графическое окно), команда выглядит так:
nssm set <имя_службы> AppEnvironmentExtra PHP_FCGI_MAX_REQUESTS=500 PHP_FCGI_CHILDREN=0
(Параметр AppEnvironmentExtra как раз добавляет ваши настройки к системным, не удаляя их).

У вас уже установлены службы через NSSM или вы только готовитесь их создавать?

Создание общедоступной ссылки…

Показать все

У виндос службы есть восстановления включать ее и перезагружать последующие сбои ?

Для работы

PHP-CGI через NSSM стандартную вкладку Windows «Восстановление» (Recovery) в свойствах службы лучше не трогать (оставить «Действие не требуется»).

Почему так?

NSSM — это «умная оболочка». Она сама выполняет роль службы восстановления, но делает это быстрее и точнее, чем стандартный менеджер Windows:

NSSM мониторит процесс постоянно: Как только php-cgi.exe закрывается (даже если он закрылся штатно по лимиту MAX_REQUESTS), NSSM видит это мгновенно и запускает его снова.
Конфликт механизмов: Если вы включите «Восстановление» в самой Windows, возникнет ситуация «масло масляное». Windows будет пытаться перезапустить саму службу NSSM, в то время как NSSM уже и так перезапускает PHP внутри себя.

Как настроить перезапуск правильно внутри NSSM:

Вместо вкладок Windows, используйте вкладку Exit actions (Действия при выходе) в конфигураторе NSSM:

Throttle: Поставьте 1500 ms (это пауза перед перезапуском, чтобы система не «захлебнулась», если PHP падает мгновенно при старте).
Restart: По умолчанию там стоит Restart application. Это именно то, что заставляет PHP подниматься бесконечное количество раз.

Когда всё же стоит включить восстановление Windows:

Только для одного случая — если упадет сама служба NSSM (что бывает крайне редко).
Если вы очень хотите подстраховаться:

Откройте «Свойства службы» в services.msc.
Вкладка Восстановление.
Первый сбой: Перезапуск службы.
Второй сбой: Перезапуск службы.
Время ожидания: 0 минут (чтобы рестарт был мгновенным).

Важный момент: Если ваш PHP падает из-за ошибки в коде или отсутствующей .dll, NSSM будет пытаться поднять его бесконечно. В логах Windows это может забить всё место.

Хотите узнать, как в NSSM настроить запись ошибок PHP в отдельный файл (вкладка I/O), чтобы видеть, почему он падает?

Создание общедоступной ссылки…

Показать все

файл конфигурации php проверь [PHP] ;;;;;;;;;;;;;;;;;;; ; About php.ini ; ;;;;;;;;;;;;;;;;;;; ; PHP's initialization file, generally called php.ini, is responsible for ; configuring many of the aspects of PHP's behavior. ; PHP attempts to find and load this configuration from a number of locations. ; The following is a summary of its search order: ; 1. SAPI module specific location. ; 2. The PHPRC environment variable. ; 3. A number of predefined registry keys on Windows ; 4. Current working directory (except CLI) ; 5. The web server's directory (for SAPI modules), or directory of PHP ; (otherwise in Windows) ; 6. The directory from the --with-config-file-path compile time option, or the ; Windows directory (usually C:\windows) ; See the PHP docs for more specific information. ; https://php.net/configuration.file ; The syntax of the file is extremely simple. Whitespace and lines ; beginning with a semicolon are silently ignored (as you probably guessed). ; Section headers (e.g. [Foo]) are also silently ignored, even though ; they might mean something in the future. ; Directives following the section heading [PATH=/www/mysite] only ; apply to PHP files in the /www/mysite directory. Directives ; following the section heading [HOST=www.example.com] only apply to ; PHP files served from www.example.com. Directives set in these ; special sections cannot be overridden by user-defined INI files or ; at runtime. Currently, [PATH=] and [HOST=] sections only work under ; CGI/FastCGI. ; https://php.net/ini.sections ; Directives are specified using the following syntax: ; directive = value ; Directive names are *case sensitive* - foo=bar is different from FOO=bar. ; Directives are variables used to configure PHP or PHP extensions. ; There is no name validation. If PHP can't find an expected ; directive because it is not set or is mistyped, a default value will be used. ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression ; (e.g. E_ALL & ~E_NOTICE), a quoted string ("bar"), or a reference to a ; previously set variable or directive (e.g. ${foo}) ; Expressions in the INI file are limited to bitwise operators and parentheses: ; | bitwise OR ; ^ bitwise XOR ; & bitwise AND ; ~ bitwise NOT ; ! boolean NOT ; Boolean flags can be turned on using the values 1, On, True or Yes. ; They can be turned off using the values 0, Off, False or No. ; An empty string can be denoted by simply not writing anything after the equal ; sign, or by using the None keyword: ; foo = ; sets foo to an empty string ; foo = None ; sets foo to an empty string ; foo = "None" ; sets foo to the string 'None' ; If you use constants in your value, and these constants belong to a ; dynamically loaded extension (either a PHP extension or a Zend extension), ; you may only use these constants *after* the line that loads the extension. ;;;;;;;;;;;;;;;;;;; ; About this file ; ;;;;;;;;;;;;;;;;;;; ; PHP comes packaged with two INI files. One that is recommended to be used ; in production environments and one that is recommended to be used in ; development environments. ; php.ini-production contains settings which hold security, performance and ; best practices at its core. But please be aware, these settings may break ; compatibility with older or less security-conscious applications. We ; recommending using the production ini in production and testing environments. ; php.ini-development is very similar to its production variant, except it is ; much more verbose when it comes to errors. We recommend using the ; development version only in development environments, as errors shown to ; application users can inadvertently leak otherwise secure information. ; This is the php.ini-production INI file. ;;;;;;;;;;;;;;;;;;; ; Quick Reference ; ;;;;;;;;;;;;;;;;;;; ; The following are all the settings which are different in either the production ; or development versions of the INIs with respect to PHP's default behavior. ; Please see the actual settings later in the document for more details as to why ; we recommend these changes in PHP's behavior. ; display_errors ; Default Value: On ; Development Value: On ; Production Value: Off ; display_startup_errors ; Default Value: On ; Development Value: On ; Production Value: Off ; error_reporting ; Default Value: E_ALL ; Development Value: E_ALL ; Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT ; log_errors ; Default Value: Off ; Development Value: On ; Production Value: On ; max_input_time ; Default Value: -1 (Unlimited) ; Development Value: 60 (60 seconds) ; Production Value: 60 (60 seconds) ; output_buffering ; Default Value: Off ; Development Value: 4096 ; Production Value: 4096 ; register_argc_argv ; Default Value: On ; Development Value: Off ; Production Value: Off ; request_order ; Default Value: None ; Development Value: "GP" ; Production Value: "GP" ; session.gc_divisor ; Default Value: 100 ; Development Value: 1000 ; Production Value: 1000 ; session.sid_bits_per_character ; Default Value: 4 ; Development Value: 5 ; Production Value: 5 ; session.sid_length ; Default Value: 32 ; Development Value: 26 ; Production Value: 26 ; short_open_tag ; Default Value: On ; Development Value: Off ; Production Value: Off ; variables_order ; Default Value: "EGPCS" ; Development Value: "GPCS" ; Production Value: "GPCS" ; zend.assertions ; Default Value: 1 ; Development Value: 1 ; Production Value: -1 ; zend.exception_ignore_args ; Default Value: Off ; Development Value: Off ; Production Value: On ; zend.exception_string_param_max_len ; Default Value: 15 ; Development Value: 15 ; Production Value: 0 ;;;;;;;;;;;;;;;;;;;; ; php.ini Options ; ;;;;;;;;;;;;;;;;;;;; ; Name for user-defined php.ini (.htaccess) files. Default is ".user.ini" ;user_ini.filename = ".user.ini" ; To disable this feature set this option to an empty value ;user_ini.filename = ; TTL for user-defined php.ini files (time-to-live) in seconds. Default is 300 seconds (5 minutes) ;user_ini.cache_ttl = 300 ;;;;;;;;;;;;;;;;;;;; ; Language Options ; ;;;;;;;;;;;;;;;;;;;; ; Enable the PHP scripting language engine under Apache. ; https://php.net/engine engine = On ; This directive determines whether or not PHP will recognize code between ; <? and ?> tags as PHP source which should be processed as such. It is ; generally recommended that <?php and ?> should be used and that this feature ; should be disabled, as enabling it may result in issues when generating XML ; documents, however this remains supported for backward compatibility reasons. ; Note that this directive does not control the <?= shorthand tag, which can be ; used regardless of this directive. ; Default Value: On ; Development Value: Off ; Production Value: Off ; https://php.net/short-open-tag short_open_tag = On ; The number of significant digits displayed in floating point numbers. ; https://php.net/precision precision = 14 ; Output buffering is a mechanism for controlling how much output data ; (excluding headers and cookies) PHP should keep internally before pushing that ; data to the client. If your application's output exceeds this setting, PHP ; will send that data in chunks of roughly the size you specify. ; Turning on this setting and managing its maximum buffer size can yield some ; interesting side-effects depending on your application and web server. ; You may be able to send headers and cookies after you've already sent output ; through print or echo. You also may see performance benefits if your server is ; emitting less packets due to buffered output versus PHP streaming the output ; as it gets it. On production servers, 4096 bytes is a good setting for performance ; reasons. ; Note: Output buffering can also be controlled via Output Buffering Control ; functions. ; Possible Values: ; On = Enabled and buffer is unlimited. (Use with caution) ; Off = Disabled ; Integer = Enables the buffer and sets its maximum size in bytes. ; Note: This directive is hardcoded

Это стандартный заголовок файла

php.ini-production. В той части текста, которую вы прислали, большинство настроек закомментированы (начинаются с ;) — это значит, что PHP использует значения по умолчанию.

Однако есть два момента, на которые стоит обратить внимание для вашей связки Nginx + PHP-CGI:

1. Что уже включено:

engine = On — обработка PHP включена (хорошо).
short_open_tag = On — разрешает использовать короткие теги <? ?>. Если ваш код старый, это нужно. Если пишете новый — лучше использовать только <?php ?>.

2. Чего НЕ хватает (важно для Nginx):

В присланном фрагменте я не вижу критически важной настройки для безопасности при работе через FastCGI. Найдите и проверьте (или добавьте) в блоке [PHP] следующую строку:

ini

cgi.fix_pathinfo = 0

Используйте код с осторожностью.

Почему это важно?
Если оставить 1 (по умолчанию), злоумышленник может заставить Nginx выполнить произвольный код, замаскированный под картинку (например, image.jpg/test.php). Установка в 0 заставляет PHP искать строго тот файл, который указан в запросе.

3. Лимиты (рекомендую проверить):

Поскольку вы настраиваете производительность, найдите в файле эти параметры и приведите их к таким (или бóльшим) значениям:

memory_limit = 256M (минимум 128M для современных скриптов).
max_execution_time = 30 (время выполнения одного скрипта в секундах).
post_max_size = 100M (максимальный размер данных в POST запросе).
upload_max_filesize = 100M (максимальный вес загружаемого файла).

4. Расширения (Extensions):

Прокрутите файл ниже до раздела Dynamic Extensions. Для работы большинства сайтов (особенно если есть база данных) вам нужно раскомментировать (убрать ;) строки:

ini

extension=curl
extension=gd
extension=mbstring
extension=mysqli
extension=openssl
extension=pdo_mysql

Используйте код с осторожностью.

И обязательно проверьте, чтобы был указан путь к папке с расширениями:
extension_dir = "ext"

Вы планируете использовать базу данных MySQL или PostgreSQL на этом сервере?

Создание общедоступной ссылки…

Показать все

это то что делает этот php video:87kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "11" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/529c039f44d575f1ba1a40ae066050581c5b0dc6e6ksyL1dMBWW19DYuMUB.video_thumb_5411_11.jpeg 2<&1 Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "25" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/9c65a219f8e946f4afad48a21c6c0d85ca5ffcc6UYL34RGNC4O2knHxEaI7.video_thumb_5411_25.jpeg 2<&1 Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "29" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/9c65a219f8e946f4afad48a21c6c0d85ca5ffcc6y7bsbmeIktojQQcZPP2U.video_thumb_5411_29.jpeg 2<&1 Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "15" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/9c65a219f8e946f4afad48a21c6c0d85ca5ffcc6XHAlZ3cT2VSBlI6CeJkU.video_thumb_5411_15.jpeg 2<&1 Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "19.5" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/9c65a219f8e946f4afad48a21c6c0d85ca5ffcc6pJeNf4eaAjmdg8tVacWU.video_thumb_5411_19.5.jpeg 2<&1 video:87kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "10" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/9c65a219f8e946f4afad48a21c6c0d85ca5ffcc61qZviRSyEvMkH7KXEOmi.video_thumb_5411_10.jpeg 2<&1 [aac @ 00000237ba451a80] Qavg: 1180.825 ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -y -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video.mp4 -vcodec libx264 -preset faster -filter:v scale=256:-2 -crf 26 I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video_144p_converted.mp4 2>&1 [aac @ 0000017cdd4bba00] Qavg: 1180.825 ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -y -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video.mp4 -vcodec libx264 -preset faster -filter:v scale=426:-2 -crf 26 -ss 0 -to 30 -async 1 I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video_shorts.mp4 2>&1 ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -t 3 -async 1 -y -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video_shorts.mp4 I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdabd918135e441c13442b478a12e6c7d1ccfcf60c0_small_video_.gif [aac @ 0000024eca81c940] Qavg: 1052.408 ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -y -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video_shorts.mp4 -vcodec libx264 -preset faster -filter:v scale=640:-2 -crf 26 I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/qF1Qur2TVrZcz99WWuB4_15_108c25b757dcad06e40bdaaf0473944f_video_shorts_360p_converted.mp4 2>&1 At least one output file must be specified ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/ZMTkZpqTNnrchF8eLM4m_26_f2a58a8106bc4329d711c1961a10c307_video.mp4 2>&1 video:92kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "11" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/ZMTkZpqTNnrchF8eLM4m_26_f2a58a8106bc4329d711c1961a10c307_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/b9fd5a91bdffae9540ade95a1bfdfd66d6b59b63gwP7n9l1I4VOh7ZusZ1z.video_thumb_5440_11.jpeg 2<&1 Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "25" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/ZMTkZpqTNnrchF8eLM4m_26_f2a58a8106bc4329d711c1961a10c307_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/b9fd5a91bdffae9540ade95a1bfdfd66d6b59b63MlVkJDGt79gXcohNbEWe.video_thumb_5440_25.jpeg 2<&1 Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "29" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/ZMTkZpqTNnrchF8eLM4m_26_f2a58a8106bc4329d711c1961a10c307_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/b9fd5a91bdffae9540ade95a1bfdfd66d6b59b63CC29waKzJVmbjfiTOG6D.video_thumb_5440_29.jpeg 2<&1 Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "15" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/ZMTkZpqTNnrchF8eLM4m_26_f2a58a8106bc4329d711c1961a10c307_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/b9fd5a91bdffae9540ade95a1bfdfd66d6b59b63iFDR7ihhfkzmoYMZcH3u.video_thumb_5440_15.jpeg 2<&1 Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) ____ I:\\Inetpub\\vudea.ru\\public_www\\ffmpeg\\ffmpeg.exe -ss "19.5" -i I:\Inetpub\vudea.ru\public_www/upload/videos/2023/09/ZMTkZpqTNnrchF8eLM4m_26_f2a58a8106bc4329d711c1961a10c307_video.mp4 -vframes 1 -f mjpeg I:\Inetpub\vudea.ru\public_www/upload/photos/2023/09/b9fd5a91bdffae9540ade95a1bfdfd66d6b59b63X2oP81WBhDQKN39w7rRp.video_thumb_5440_19.5.jpeg 2<&1 echo $uotput = exec("$str");

Ого, теперь понятно! Ваш PHP занимается очень тяжелой работой —

перекодированием видео через FFmpeg. Это меняет всё дело.

Для такой задачи стандартные настройки PHP точно не подходят. Вот что вам нужно исправить в php.ini и конфигах, чтобы сервер не «падал» и видео обрабатывалось:

1. Увеличьте лимиты времени (самое важное)

Перекодирование видео может длиться минутами или часами. По умолчанию PHP убивает скрипт через 30 секунд.
В php.ini найдите и измените:

max_execution_time = 0 (0 — это бесконечно, скрипт не закроется, пока FFmpeg не закончит работу).
max_input_time = 600 (время на загрузку видео на сервер).
memory_limit = 512M (или больше, FFmpeg сам потребляет память, но PHP тоже нужен запас для управления процессом).

2. Настройка Nginx (Таймауты)

Nginx тоже не будет ждать PHP вечно. Если PHP молчит, пока FFmpeg крутит видео, Nginx выдаст ошибку 504 Gateway Timeout.
В блоке location ~ \.php$ добавьте:

nginx

fastcgi_read_timeout 3600s; # Ждать ответа от PHP до 1 часа
fastcgi_send_timeout 3600s;
fastcgi_connect_timeout 60s;

Используйте код с осторожностью.

3. Нюанс с worker_processes и количеством PHP

Перекодирование видео (libx264) — это процесс, который съедает 100% одного или нескольких ядер.

Если у вас 4 ядра и вы запустите 4 процесса PHP, которые одновременно начнут кодировать видео, сервер полностью зависнет. Nginx даже не сможет ответить на запрос "Главная страница".
Рекомендация: Оставьте 1-2 ядра «свободными» для системы и Nginx. Если у вас 4 ядра, лучше запускать только 2-3 службы PHP через NSSM для таких тяжелых задач.

4. Почему в логах "Output file is empty"?

В вашем выводе много ошибок nothing was encoded. Это часто случается, когда:

Права доступа: PHP-процесс (запущенный через NSSM) не имеет прав на запись в папку I:\Inetpub\vudea.ru\.... Проверьте, от какого пользователя запущены службы в NSSM (лучше от System или администратора).
Пути: У вас в команде смешаны прямые и обратные слеши: .../public_www\ffmpeg\ffmpeg.exe. Windows это часто прощает, но FFmpeg иногда капризничает.
Таймаут в коде: Если вы используете exec(), убедитесь, что PHP не обрывает связь раньше времени.

Совет по FFmpeg: В командах нарезки превью (-ss) попробуйте ставить параметр -ss ДО параметра -i. Так FFmpeg работает намного быстрее, особенно с большими файлами.

Ваш сервер сильно тормозит, когда кто-то загружает видео?

Создание общедоступной ссылки…

Показать все

по умолчанию если не настраивать это fastcgi_read_timeout 3600s; # Ждать ответа от PHP до 1 часа fastcgi_send_timeout 3600s; fastcgi_connect_timeout 60s;

Если эти параметры

не настраивать, Nginx использует свои стандартные (жесткие) лимиты. Для обработки видео это почти всегда заканчивается ошибкой.

Вот значения по умолчанию:

fastcgi_read_timeout — 60 секунд.
Это ваша главная проблема. Если FFmpeg кодирует ролик дольше 1 минуты, Nginx просто «вешает трубку», не дождавшись ответа от PHP, и пользователь видит 504 Gateway Timeout. При этом сам процесс FFmpeg может остаться «висеть» в системе, пожирая ресурсы.
fastcgi_send_timeout — 60 секунд.
Столько Nginx готов ждать при передаче данных в PHP. Обычно этого хватает, если вы не закачиваете файлы по 10 Гб через очень медленный интернет.
fastcgi_connect_timeout — 60 секунд.
Время, за которое Nginx должен успеть «постучаться» к порту PHP (например, 9123). Если все ваши 4 порта PHP наглухо заняты кодированием видео и не принимают новые соединения, через минуту Nginx выдаст 502 Bad Gateway.

Что происходит в вашем случае (с видео):

Кодирование видео — процесс долгий. Без ручной настройки на 3600s (или хотя бы 300s — 5 минут), цепочка будет постоянно рваться:

Пользователь нажал «Загрузить».
PHP запустил exec(ffmpeg...).
Прошло 60 секунд.
Nginx оборвал соединение и показал ошибку.
Пользователь думает, что всё сломалось, и нажимает «Загрузить» еще раз.
В системе запускается второй тяжелый процесс FFmpeg поверх первого.
Сервер «умирает» от перегрузки процессора.

Рекомендация:
Для сайта с видео обязательно пропишите fastcgi_read_timeout хотя бы на 300-600 секунд. Это даст PHP время спокойно дождаться завершения работы FFmpeg и ответить Nginx, что «всё готово».

Ваш FFmpeg обычно справляется быстрее чем за минуту или дольше?

Создание общедоступной ссылки…

Показать все

fastcgi_next_upstream error timeout invalid_header http_500 http_503; fastcgi_next_upstream_timeout 3s; # не пытаться переключать дольше 10 секунд fastcgi_read_timeout 3600s; # Ждать ответа от PHP до 1 часа fastcgi_send_timeout 3600s; fastcgi_connect_timeout 60s;

В этой конфигурации есть

скрытая ловушка, которая может «положить» ваш сервер при обработке видео.

Проблема в сочетании fastcgi_next_upstream_timeout 3s и fastcgi_read_timeout 3600s.

Что произойдет на практике:

Конфликт таймаутов: Вы разрешили PHP работать 1 час (read_timeout 3600s), но при этом приказали Nginx переключаться на следующий поток, если ответа нет 3 секунды (next_upstream_timeout 3s).
Цепная реакция: Когда запустится тяжелый FFmpeg, он явно не ответит за 3 секунды. Nginx подумает: "Ой, порт 9123 молчит больше 3 секунд, попробую-ка я порт 9124".
Итог: Nginx за 12 секунд (4 порта по 3 секунды) запустит четыре тяжелых процесса FFmpeg на один и тот же файл. Процессор уйдет в 100% нагрузку, а пользователь всё равно получит ошибку, так как лимит в 3 секунды выйдет на всех портах.

Как исправить (Рекомендация):

Для обработки видео логику нужно изменить. Если PHP начал работать (кодировать), Nginx должен терпеливо ждать именно этот процесс, а не прыгать по другим портам.

Правильный вариант для вашего случая:

nginx

location ~ \.php$ {
    root           D:\AUTOUP;
    include        fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass   php_workers;

    # 1. Ждем ответа от PHP долго (для видео)
    fastcgi_read_timeout 3600s;
    fastcgi_send_timeout 3600s;
    fastcgi_connect_timeout 60s;

    # 2. Настраиваем переключение ПРАВИЛЬНО
    # Переключаемся на другой PHP, ТОЛЬКО если порт закрыт (error) 
    # или PHP сразу отказал (503), но НЕ по таймауту ожидания видео.
    fastcgi_next_upstream error invalid_header http_503; 
    
    # 3. Убираем или сильно увеличиваем этот лимит
    # Чтобы Nginx не бросал запрос, пока PHP кодирует файл
    fastcgi_next_upstream_timeout 0; 
}

Используйте код с осторожностью.

Почему так лучше:

Убрав timeout из списка fastcgi_next_upstream, вы запрещаете Nginx плодить копии FFmpeg на других портах, если первый порт просто "задумался" над видео.
fastcgi_read_timeout 3600s даст вашему скрипту спокойно доработать до конца.

У вас FFmpeg запускается напрямую через exec() или вы используете какую-то очередь (например, через базу данных)?

Создание общедоступной ссылки…

Показать все

или один час fastcgi_next_upstream_timeout 0; как fastcgi_send_timeout или не нужно?

Параметр

fastcgi_next_upstream_timeout 0; не означает один час. В Nginx значение 0 отключает ограничение по времени на попытки переключений между бекендами [1, 2].

Как это работает в паре с fastcgi_read_timeout 3600s:

fastcgi_read_timeout 3600s: Это время ожидания ответа от одного конкретного процесса PHP [4, 6]. Если ваш FFmpeg кодирует видео 40 минут, Nginx будет терпеливо ждать все 40 минут.
fastcgi_next_upstream_timeout 0: Это общее время, которое Nginx может потратить на все попытки перебора ваших портов (9123, 9124 и т.д.) [1, 2]. Если вы поставите 0, Nginx будет пробовать следующий порт столько раз, сколько разрешено в max_fails, не ограничивая это общим секундомером [2].

Нужно ли ставить 1 час в next_upstream_timeout?

Нет, не нужно.

Для вашей задачи с видео лучше всего оставить 0 или вообще не использовать timeout в списке переключений.

Почему?
Если вы кодируете видео, и первый PHP-процесс (порт 9123) "молчит" (обрабатывает файл), вы не хотите, чтобы Nginx через какое-то время решил: "Ой, долго ждем, попробую-ка я порт 9124". Если он так сделает, у вас запустятся два тяжелых FFmpeg на один и тот же файл, что перегрузит процессор в два раза сильнее [3, 5].

Идеальная настройка для видео:

nginx

# Ждем ответа от конкретного PHP до 1 часа
fastcgi_read_timeout 3600s; 

# Переключаемся на другой порт ТОЛЬКО если PHP упал (error) 
# или порт закрыт, но НЕ если он просто долго думает (убираем timeout)
fastcgi_next_upstream error invalid_header http_502 http_503;

# Не ограничиваем общее время попыток перебора (пусть решит max_fails)
fastcgi_next_upstream_timeout 0;

Используйте код с осторожностью.

Важное замечание:
Если вы уберете слово timeout из строки fastcgi_next_upstream, то параметр fastcgi_next_upstream_timeout вообще перестанет влиять на "задумчивость" PHP при кодировании видео. Nginx будет просто ждать ровно столько, сколько указано в fastcgi_read_timeout [4, 6].

Ваш скрипт PHP выдает какой-то текст в процессе кодирования (прогресс) или молчит до самого конца?

Создание общедоступной ссылки…

Показать все

fastcgi_next_upstream error timeout invalid_header http_500 http_503; fastcgi_next_upstream_timeout 0; # 3s; # не пытаться переключать дольше 10 секунд fastcgi_read_timeout 3600s; # Ждать ответа от PHP до 1 часа fastcgi_send_timeout 3600s; fastcgi_connect_timeout 60s;

Этот вариант конфигурации

рабочий, но он несет в себе риск дублирования тяжелых задач (перекодирования видео).

Что произойдет при такой настройке:

fastcgi_read_timeout 3600s: Nginx будет ждать ответа от одного процесса PHP (например, на порту 9123) целый час.
timeout в списке fastcgi_next_upstream: Если через час PHP так и не ответит (например, видео очень тяжелое или процесс завис), Nginx не покажет ошибку, а попробует отправить этот же запрос на порт 9124.
fastcgi_next_upstream_timeout 0: Nginx не ограничен по времени в своих попытках перебрать все ваши 4 порта.

В чем главная опасность для FFmpeg:

Если ваш PHP-скрипт просто запускает ffmpeg и ничего не выводит в браузер (не делает echo или flush) в процессе работы, Nginx считает это "молчанием".

Если по какой-то причине время обработки превысит 1 час (3600s), Nginx решит, что первый процесс "отвалился" по таймауту.
Он перекинет запрос на второй порт.
Итог: У вас в системе будут работать два процесса FFmpeg одновременно над одним и тем же файлом. Это создаст колоссальную нагрузку на диски и процессор.

Моя рекомендация:

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

Если же вы хотите подстраховаться от "двойной работы" процессора, лучше убрать слово timeout из списка переключений:

nginx

# Оставляем только критические ошибки для переключения
fastcgi_next_upstream error invalid_header http_500 http_503;

Используйте код с осторожностью.

Почему так лучше?
В этом случае, если PHP промолчит больше часа, Nginx просто выдаст пользователю ошибку "504 Gateway Timeout", но не будет пытаться запустить ту же тяжелую задачу на следующем порту, спасая ваш сервер от перегрузки.

Ваш FFmpeg обычно успевает обработать ролик за этот час или бывают файлы по несколько гигабайт?

Создание общедоступной ссылки…

Показать все

fastcgi_next_upstream error invalid_header http_500 http_503; #error timeout invalid_header http_500 http_503 fastcgi_next_upstream_timeout 0; # 3s; # не пытаться переключать дольше 10 секунд fastcgi_read_timeout 3600s; # Ждать ответа от PHP до 1 часа fastcgi_send_timeout 3600s; fastcgi_connect_timeout 60s;

Этот вариант конфигурации —

самый безопасный и правильный для работы с тяжелым видео (FFmpeg).

Почему этот конфиг идеален для вас:

Защита от «мультипликации» нагрузки: Убрав timeout из списка fastcgi_next_upstream, вы запретили Nginx запускать повторный FFmpeg на другом порту, если первый процесс просто долго (до часа) кодирует видео.
Огромный запас времени: fastcgi_read_timeout 3600s дает вашему PHP целый час на обработку. Даже если файл большой, Nginx не разорвет соединение.
Умное переключение: Nginx перекинет запрос на другой порт PHP (9124, 9125...) только если текущий порт физически закрыт (error) или выдал критическую ошибку сервера (http_500). Это именно то, что нужно для стабильности.

Маленький нюанс:

В списке fastcgi_next_upstream я бы рекомендовал добавить еще http_502 http_504, на случай если PHP-процесс упадет или сам выдаст ошибку шлюза:

nginx

fastcgi_next_upstream error invalid_header http_500 http_502 http_503 http_504;

Используйте код с осторожностью.

(Но даже без этого ваша текущая строка уже на 95% закрывает все риски).

Как вы планируете запускать перекодирование: сразу при загрузке пользователем или через какую-то фоновую очередь?

Создание общедоступной ссылки…

Показать все

мне думалось переделать под nodejs декодирование чтобы через php просто отправить только запрос в путем какой файл декодировать и какой строкой декодировать

Это отличная идея! Перенос тяжелой обработки видео на

Node.js — это классический способ разгрузить веб-сервер. Node.js гораздо лучше подходит для управления внешними процессами (FFmpeg), чем PHP.

Почему это лучше:

PHP не «виснут»: Ваши 4 процесса PHP (9123-9126) будут свободны. Они просто отправят быстрый HTTP-запрос в Node.js и сразу ответят пользователю «Ваше видео обрабатывается».
Очередь задач: В Node.js легко сделать очередь (например, через Bull или просто массив). Если 10 человек одновременно загрузят видео, Node.js будет обрабатывать их по 2-3 штуки (по количеству ядер), а остальные будут ждать своей очереди, не «вешая» весь сервер.
События в реальном времени: Node.js может через WebSockets (Socket.io) сообщать пользователю: «Обработано 10%... 20%...», чего в обычном PHP сделать крайне сложно.

Как будет выглядеть схема:

PHP: Получает файл, сохраняет его в папку upload/temp и делает запрос к Node.js:
file_get_contents("http://localhost:3000/process?file=video.mp4");
Node.js: Принимает запрос, добавляет задачу в список.
FFmpeg: Node.js запускает FFmpeg через child_process.spawn.
Результат: Когда видео готово, Node.js может сам переместить файл в нужную папку или вызвать «callback» (сообщить PHP, что всё готово).

Как изменить конфиг Nginx:

Вам придется добавить блок для Node.js (например, на порт 3000):

nginx

location /node/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_read_timeout 3600s; # Также ставим длинный таймаут
}

Используйте код с осторожностью.

Вы уже знакомы с библиотеками для очередей в Node.js или хотите сделать простую систему на child_process?

Создание общедоступной ссылки…

Показать все

сделай примеры подробно объясняя варианты

Для реализации переноса видео на Node.js есть два основных пути:

простой (через прямой запрос) и профессиональный (через очередь).

Вариант 1: Прямой запрос (PHP -> Node.js)

Это самый быстрый способ. PHP передает данные в Node.js через HTTP-запрос, а Node.js запускает FFmpeg.

Как это работает:

PHP получает файл и сохраняет его.
PHP делает curl или file_get_contents на адрес http://127.0.0.
Node.js запускает процесс.

Пример кода на Node.js (Express):

javascript

const express = require('express');
const { spawn } = require('child_process');
const app = express();

app.get('/encode', (req, res) => {
    const inputFile = req.query.file; // например, I:/videos/input.mp4
    const outputFile = inputFile + '_converted.mp4';

    // Запускаем FFmpeg как отдельный процесс
    const ffmpeg = spawn('ffmpeg', ['-i', inputFile, '-vcodec', 'libx264', outputFile]);

    ffmpeg.stdout.on('data', (data) => console.log(`stdout: ${data}`));
    ffmpeg.stderr.on('data', (data) => console.log(`stderr: ${data}`));

    ffmpeg.on('close', (code) => {
        console.log(`Процесс завершен с кодом ${code}`);
        // Здесь можно вызвать скрипт PHP, чтобы обновить статус в БД
    });

    // Отвечаем PHP сразу, чтобы он не висел
    res.send('Обработка запущена');
});

app.listen(3000, () => console.log('Node.js видео-сервер на порту 3000'));

Используйте код с осторожностью.

Плюсы: Легко настроить.
Минусы: Если 10 человек нажмут кнопку одновременно, Node.js запустит 10 FFmpeg, и процессор «умрет».

Вариант 2: Через очередь задач (Рекомендуемый)

Чтобы не перегружать сервер, задачи ставятся в очередь и выполняются по очереди (например, по 2 видео одновременно).

Как это работает:

PHP просто записывает путь к файлу в базу данных (MySQL) со статусом waiting.
Node.js раз в 5 секунд проверяет БД: «Есть ли работа?».
Если находит — берет файл, кодирует, и меняет статус в БД на ready.

Пример логики на Node.js:

javascript

const mysql = require('mysql2/promise');
const { exec } = require('child_process');

async function checkQueue() {
    const connection = await mysql.createConnection({/* настройки БД */});
    
    // Ищем одну задачу со статусом 'waiting'
    const [rows] = await connection.execute('SELECT * FROM video_queue WHERE status = "waiting" LIMIT 1');

    if (rows.length > 0) {
        const task = rows[0];
        await connection.execute('UPDATE video_queue SET status = "processing" WHERE id = ?', [task.id]);

        console.log(`Начинаем кодировать: ${task.file_path}`);

        exec(`ffmpeg -i ${task.file_path} ...`, async (error) => {
            if (error) {
                await connection.execute('UPDATE video_queue SET status = "error" WHERE id = ?', [task.id]);
            } else {
                await connection.execute('UPDATE video_queue SET status = "ready" WHERE id = ?', [task.id]);
            }
            // После завершения проверяем следующую задачу
            checkQueue();
        });
    } else {
        // Если задач нет, проверим снова через 5 секунд
        setTimeout(checkQueue, 5000);
    }
}

checkQueue();

Используйте код с осторожностью.

Почему это лучше для вашего Nginx:

В обоих вариантах ваш конфиг Nginx для PHP становится «легким»:

Вам больше не нужны fastcgi_read_timeout 3600s.
PHP отвечает пользователю за 0.1 сек: «Видео принято, подождите».
Пользователь видит на сайте иконку «Обработка...» (которую вы подтягиваете из БД).

Что выбрать?

Если у вас мало посетителей — делайте Вариант 1.
Если планируете много видео — только Вариант 2, иначе сервер будет постоянно виснуть от перегрузки CPU.

Какой вариант вам ближе по логике вашего сайта?

Создание общедоступной ссылки…

Показать все

объясни nodejs 3000 порту если уже запущено то уже на этом порту не запуститься ? Или возможно что то такое 127.0.0.2:3001 ....3009 потом 127.0.0.3:3001 ... и так далее

В сетевых технологиях (и в Node.js в частности) действует строгое правило:

один порт — один процесс. Если программа заняла порт 127.0.0.1:3000, вторая программа при попытке запуститься на этом же порту выдаст ошибку EADDRINUSE (адрес уже используется).

Однако, ваши идеи про разные IP и порты технически реализуемы. Давайте разберем подробнее:

1. Можно ли запустить на 127.0.0.1, 127.0.0.2 и т.д.?

Да, можно. Вся подсеть 127.0.0.0/8 (от 127.0.0.1 до 127.255.255.254) зарезервирована за вашим локальным компьютером (loopback).

Вы можете запустить один Node.js на 127.0.0.1:3000.
Второй Node.js на 127.0.0.2:3000.
Они не будут конфликтовать, так как комбинация IP + Порт у них разная.

Но в этом мало смысла, потому что физический процессор и оперативная память у сервера одни и те же. Проще использовать разные порты на одном IP (127.0.0.1:3001, :3002 и т.д.).

2. Как запустить много копий Node.js (Кластеризация)

Если вы хотите, чтобы Node.js работал на всех ядрах процессора (как ваши 4 процесса PHP), есть три пути:

А. Ручной запуск (как вы делали с PHP)

Вы запускаете несколько скриптов на разных портах:

node server.js --port 3000
node server.js --port 3001
И в Nginx прописываете их в upstream, точно так же, как делали для PHP.

Б. Использование модуля Cluster (встроенный в Node.js)

Node.js умеет сам создавать свои копии. Один "мастер"-процесс занимает порт 3000 и сам распределяет входящие запросы между "дочерними" процессами. Вам не нужно менять конфиг Nginx — для него это выглядит как один сервер.

В. PM2 (Профессиональный стандарт)

Это менеджер процессов (как NSSM, но специально для Node.js). Одной командой можно запустить копии на все ядра:

bash

pm2 start server.js -i max

Используйте код с осторожностью.

PM2 сам будет следить, чтобы они не падали, и сам распределит нагрузку.

3. Зачем это нужно для видео?

Для FFmpeg не нужно запускать 10 копий Node.js на разных портах.

Node.js по своей природе асинхронный. Один процесс Node.js может принять 100 запросов на кодирование видео одновременно.
Он просто запустит 100 процессов ffmpeg.exe.
Проблема: Если он запустит 100 FFmpeg одновременно, сервер "умрет".

Вывод: Вместо того чтобы плодить порты (3001, 3002...), в Node.js лучше сделать один сервер, который внутри себя имеет лимит (например: "одновременно кодировать не более 2 видео, остальные — в очередь").

Хотите пример кода для Node.js, который сам ограничивает количество одновременно работающих FFmpeg?

Создание общедоступной ссылки…

Показать все

если на сервере уже запущены другие nodejs с другими задачами

Если на сервере уже работают другие приложения на Node.js, вам просто нужно выделить для своего нового видео-сервиса

уникальный свободный порт (например, 3005, 4000 и т.д.). Они никак не будут мешать друг другу, так как каждый процесс Node.js в Windows работает в своем изолированном пространстве памяти.

Вот как правильно организовать работу нескольких Node.js приложений:

1. Проверка свободных портов

Перед запуском проверьте, какие порты уже заняты вашими старыми скриптами. В командной строке Windows:

cmd

netstat -ano | findstr :3000

Используйте код с осторожностью.

Если команда что-то вывела — порт занят. Выбирайте следующий (3001, 3002...).

2. Изоляция через разные порты (рекомендуется)

Вы просто запускаете новый скрипт на новом порту. В коде Node.js:

javascript

const PORT = 3005; // Этот порт свободен и не занят другими вашими Node-скриптами
app.listen(PORT, () => console.log(`Видео-сервер запущен на порту ${PORT}`));

Используйте код с осторожностью.

В конфиге Nginx вы просто добавляете новый upstream или location специально для этого порта:

nginx

location /api/encode {
    proxy_pass http://127.0.0.1:3005; 
    proxy_read_timeout 3600s;
}

Используйте код с осторожностью.

3. Использование разных IP (127.0.0.2, 127.0.0.3)

Это возможно, но неудобно. Вам придется в коде Node.js явно указывать IP:

javascript

app.listen(3000, '127.0.0.2');

Используйте код с осторожностью.

Это полезно только в одном случае: если у вас два разных приложения обязательно должны использовать порт 3000 (например, так зашито в их коде). В остальных случаях лучше просто менять номер порта.

4. Проблема ресурсов (CPU)

Это самый важный момент. Другие ваши Node.js процессы (например, чат или API) могут начать тормозить, когда запустится FFmpeg.

Node.js (чат/API): Потребляет мало ресурсов, в основном ждет сеть.
FFmpeg (видео): Пожирает весь процессор.

Как решить:
В команде запуска FFmpeg внутри Node.js добавьте ограничение по количеству потоков (параметр -threads). Например, если у вас 8 ядер, разрешите FFmpeg использовать только 4:

javascript

const ffmpeg = spawn('ffmpeg', ['-i', input, '-threads', '4', output]);

Используйте код с осторожностью.

Так остальные 4 ядра останутся для ваших других Node.js приложений, Nginx и PHP.

Итог:

Выберите любой свободный порт (например, 3005).
Запустите на нем новый сервис обработки видео.
Ограничьте количество потоков FFmpeg, чтобы он не "задушил" другие ваши Node.js задачи.

Хотите код на Node.js, который будет автоматически проверять загрузку процессора перед тем, как запустить новое видео на перекодировку?

Создание общедоступной ссылки…

Показать все

Результаты поиска