Я недавно переключил свою конфигурацию php7.3-fpm на использование сокетов UNIX вместо прослушивания на localhost: 9000. Это решило проблема с задержкой (время от времени у меня были запросы, которые занимали секунду без причины). Но теперь, используя сокеты unix, я получаю проблемы "503 service unavailable" с высокими нагрузками - но только для PHP-скриптов . Статические файлы по-прежнему доставляются без ошибок. Следовательно, это что-то связано с PHP.
Я протестировал сайт с помощью k6 . При ~ 400 запросов / с простой скрипт набирает 90 % 503-ошибок при тестировании, тогда как при использовании TCP он просто замедляется до бесконечности и вроде работает даже при 800 запросах / с, имея только ~ 0,5% неудачных запросов. Я предполагаю, что это своего рода ограничение на соединения в сокете UNIX. пришлось увеличить размер невыполненной работы в /etc/php/7.3/fpm/pool.d/www.conf
, чтобы TCP работал с такими высокими нагрузками (до 10240, что в 10 раз больше d efault). Но я не нашел ничего похожего для сокетов UNIX в конфигурации ... Я также попытался увеличить количество файловых дескрипторов, которые lighttpd может использовать (server.max-fds), но безуспешно.
Поскольку сокеты UNIX более эффективны, я бы хотел их использовать. Тем более, что они как бы решили эту проблему с задержкой ...и им не нужно проходить брандмауэр, который по какой-то причине блокирует соединения localhost, начиная с более новой версии ядра. Для сокетов UNIX может быть ограничение на количество подключений ... но я не знаю, как его установить.
Знаете ли вы, ПОЧЕМУ это ... или у вас есть решение проблемы?
lighttpd: 1.4.53 (невозможно обновить до последняя версия!) php-fpm: 7.3 ОС: debian / 9.13 Версия ядра: "Linux worldtalk.de 4.9.0-15-amd64 # 1 SMP Debian 4.9 .258-1 (2021-03-08) x86_64 GNU / Linux ".
/etc/lighttpd/lighttpd.conf
.
.
.
server.port = 80
server.stream-request-body = 2
server.stream-response-body = 2
server.listen-backlog = 2000
server.max-keep-alive-idle = 2
server.max-keep-alive-requests = 4
server.max-read-idle = 25
server.max-write-idle = 25
server.max-fds = 10240
.
.
.
/etc/lighttpd/conf-enabled/10-fastcgi.conf
Для сокетов UNIX:
server.modules += ( "mod_fastcgi" )
index-file.names += ( "index.php" )
fastcgi.server = (
".php" => (
"localhost" => (
"socket" => "/run/php/php7.3-fpm.sock",
"broken-scriptfilename" => "enable"
))
)
и для TCP:
server.modules += ( "mod_fastcgi" )
index-file.names += ( "index.php" )
fastcgi.server = ( ".php" => ((
"host" => "127.0.0.1",
"port" => "9000",
"broken-scriptfilename" => "enable"
)))
/ etc / php / 7.3 / fpm / pool.d / www.conf
user = www-data
group = www-data
listen = 127.0.0.1:9000
;listen = /run/php/php7.3-fpm.sock <--- THIS IS USED FOR UNIX SOCKETS
listen.backlog = 10240
listen.owner = www-data
listen.group = www-data
process.priority = -18
pm = dynamic
pm.max_children = 2000
pm.start_servers = 15
pm.min_spare_servers = 10
pm.max_spare_servers = 15
pm.max_requests = 0
.
.
.
-
После дополнительных поисков я нашел решение здесь: How to set unix socket backlog with systemd?
Which essentially says...
Из listen(2):
Если аргумент backlog больше, чем значение в /proc/sys/net/core/somaxconn, то он молча усекается до этого значения. значение; значение по умолчанию в этом файле равно 128. В ядрах до версии 2.4.25, это ограничение было жестко закодированным значением, SOMAXCONN, со значением 128.
Поэтому я установил "SOMAXCONN" в 10240, чтобы не ограничивать отставание для unix-сокетов, и это увеличило размер отставания для UNIX-сокетов и решило проблему:
echo "10240" > /proc/sys/net/core/somaxconn
для быстрого исправления и тестирования... Чтобы сделать его постоянным, добавьте следующую строку в /etc/sysctl.conf
:
net.core.somaxconn = 10240