mpm_prefork: error (11) Ресурс временно недоступен: AH00159: fork: Невозможно разветвить новый процесс

После возникли некоторые проблемы я перестроил свой сервер на новую, чистую платформу Fedora 24. Это довольно загруженный сервер, и теперь, когда он запускается, я получаю поток этих сообщений в error_log apache:

[Thu Dec 08 19:30:26.954314 2016] [mpm_prefork:error] [pid 379] (11)Resource temporarily unavailable: AH00159: fork: Unable to fork new process
[Thu Dec 08 19:30:36.957269 2016] [mpm_prefork:error] [pid 379] (11)Resource temporarily unavailable: AH00159: fork: Unable to fork new process
[Thu Dec 08 19:30:46.963876 2016] [mpm_prefork:error] [pid 379] (11)Resource temporarily unavailable: AH00159: fork: Unable to fork new process
[Thu Dec 08 19:30:56.967167 2016] [mpm_prefork:error] [pid 379] (11)Resource temporarily unavailable: AH00159: fork: Unable to fork new process
[Thu Dec 08 19:31:06.974127 2016] [mpm_prefork:error] [pid 379] (11)Resource temporarily unavailable: AH00159: fork: Unable to fork new process

Я пробовал настраивать и настраивать, но, похоже, ничего не решает проблему. Я использую ту же самую машину, которая отлично работала под Fedora 23, поэтому я знаю, что она может справиться с нагрузкой.

Вот мой статус сервера apache:

Apache Server Status for example.com (via x.x.x.x)

Server Version: Apache/2.4.23 (Fedora) OpenSSL/1.0.2j-fips PHP/5.6.28
Server MPM: prefork
Server Built: Jul 18 2016 15:38:14
Current Time: Thursday, 08-Dec-2016 19:38:57 UTC
Restart Time: Thursday, 08-Dec-2016 19:29:02 UTC
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 9 minutes 55 seconds
Server load: 2.86 2.38 1.48
Total accesses: 13045 - Total Traffic: 112.5 MB
CPU Usage: u485.32 s25.57 cu.05 cs.03 - 85.9% CPU load
21.9 requests/sec - 193.6 kB/second - 8.8 kB/request
165 requests currently being processed, 0 idle workers
KKKKWKKKKKKKKKKKKKKWKKKKKWKKKKKWWKKKKKKKKKKWKKKWKKKWKKKKKKKWWKKW
WKKKKKKKKKKWKKKKKKWKKKWKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKWKKK
KKKKKKKWWKKKKWKKKKKKKKWKKKKKKKKKKKWKW...........................
................................................................
................................................................
................................................................

... и дальше все будет дальше. Есть много открытых слотов, но что-то на сервере препятствует запуску новых процессов и обработке нагрузки. Однако мои ulimits установлены высокими - возможно, слишком высокими!

# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 1546671
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 102400
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1546671
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Для полноты, вот мои настройки limits.conf:

*            soft    core            unlimited
*            soft    nofile          102400
*            hard    nofile          152400
*            soft    sigpending      1546671
*            hard    sigpending      2046671
*            soft    stack           10240
*            hard    stack           14240
*            soft    nproc           1546671
*            hard    nproc           2046671

И вот мои настройки apache mpm-worker - опять же, вероятно, слишком высокие, Майк

0
задан 13 April 2017 в 15:14
2 ответа

Предварительное решение - добавить следующее в httpd.conf:

EnableMMAP Off

Это отключает отображение памяти, которое, по всей видимости, оказало очень неблагоприятное воздействие на сервер.

Подробнее см. ​​http://httpd.apache.org/docs/2.4/mod/core.html#enablemmap

Если окажется, что это не решение, я сообщу людям здесь.

0
ответ дан 5 December 2019 в 09:06

У нас была аналогичная проблема. Похоже, что systemd был причиной нашего ограничения.

https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#TasksMax=N

-1
ответ дан 18 February 2020 в 08:43

Теги

Похожие вопросы