On 6.12.3 I keep getting this warning and the UI becomes unresponsive.

Just rebooted after the server was unresponsive for 12+hours when shfs: share cache full and i've seen the error a few times already.

 

php-fpm[8997]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

 

I have never seen this before and on 7.0 beta 1 i'm seeing it

still having this problems after years, all my crashes are related to this, pls fix

Same here, so far for me at least it points either to GPU statistics plugin or (most likely) frigate container (ver 0.14)

@ljm42 its a very serious problem, we need a fix, every time my server crash is for this, and now it crash almost daily, I tried upping pm.max_children to 100 and pm.max_request to 500

will see how it goes

unraid-diagnostics-20240901-1713.zip

I’m also seeing this error in my logs now.  Server has 36 cores and 256GB RAM And a 4TB NVMe cache with more than 75% space.  No other clues what is causing it.

I am getting this now.

php-fpm[65769]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Was there any reason for it?

On 9/23/2025 at 1:26 AM, Fuggin said:

I am getting this now.

php-fpm[65769]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Was there any reason for it?

I have been seeing this too lately. Maybe it started 1 weeks ago so, not really sure.

php-fpm[9141]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Edited October 6, 2025Oct 6 by uCoreX

Not sure if this is new for me, but my server has been pretty stable, until tonight when Plex was being used, it crashed twice. I also have GPU statistics installed, but the GPU really doesnt get used for anything but Plex transcodeing. The crash didnt happen until an hour after this warning, but its the only thing in the syslog with a warning.

+1.. Removing GPU Statistics worked for me also. It seems to have made things more stable and faster responding in the 4 hours I've had it removed.

I am running into this now as well. I do not have the GPU statistics installed but I am also in the middle of replacing a 10TB drive with a 26TB drive. The rebuild was running fine until this morning, i got that error and noticed my rebuilt was now 17days. I ended up stopping Docker and i am back to 1day 15hours. I don't know if that error had anything to do with Docker or not but I am leaving it off until the rebuild is finished and I can investigate more.

I also got this message and went according to this tutorial: https://www.c-rieger.de/nextcloud-und-php-troubleshooting/

Still an issue in v7.2.0, switched to dynamic, love how we are using static values on a scalable platform... /etc/php-fpm.d/www.conf

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;             pm.max_spawn_rate    - the maximum number of rate to spawn child
;                                    processes at once.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
; limetech - let's use ondemand
;pm = dynamic
;pm = ondemand
pm = dynamic

cranked max_children up

; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes when pm is set to 'dynamic' or 'ondemand'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
; CGI. The below defaults are based on a server without much resources. Don't
; forget to tweak pm.* to fit your needs.
; Note: Used when pm is set to 'static', 'dynamic' or 'ondemand'
; Note: This value is mandatory.
pm.max_children = 150

; The number of child processes created on startup.
; Note: Used only when pm is set to 'dynamic'
; Default Value: (min_spare_servers + max_spare_servers) / 2
pm.start_servers = 3

; The desired minimum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.min_spare_servers = 3

; The desired maximum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.max_spare_servers = 5

and just like magic the UI is responsive again.

(37 dockers, 3 vms, 1.000 processes, i9-12900K cpu with 128GB memory of which 12GB used (rest goes to linux buffer), nvme exclusive shares)

Edited December 20, 2025Dec 20 by Samsonight
clarifications

On 11/15/2025 at 5:30 AM, Samsonight said:

Still an issue in v7.2.0, switched to dynamic, love how we are using static values on a scalable platform...

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;             pm.max_spawn_rate    - the maximum number of rate to spawn child
;                                    processes at once.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
; limetech - let's use ondemand
;pm = dynamic
;pm = ondemand
pm = dynamic

cranked max_children up

; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes when pm is set to 'dynamic' or 'ondemand'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
; CGI. The below defaults are based on a server without much resources. Don't
; forget to tweak pm.* to fit your needs.
; Note: Used when pm is set to 'static', 'dynamic' or 'ondemand'
; Note: This value is mandatory.
pm.max_children = 150

; The number of child processes created on startup.
; Note: Used only when pm is set to 'dynamic'
; Default Value: (min_spare_servers + max_spare_servers) / 2
pm.start_servers = 3

; The desired minimum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.min_spare_servers = 3

; The desired maximum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.max_spare_servers = 5

and just like magic the UI is responsive again.

(37 dockers, 3 vms, 1.000 processes, i9-12900K cpu with 128GB memory of which 12GB used (rest goes to linux buffer), nvme exclusive shares)

Did the same just right now. Will see how it behaves. You're still ok?

On 11/15/2025 at 5:30 AM, Samsonight said:

Still an issue in v7.2.0, switched to dynamic, love how we are using static values on a scalable platform...

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;             pm.max_spawn_rate    - the maximum number of rate to spawn child
;                                    processes at once.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
; limetech - let's use ondemand
;pm = dynamic
;pm = ondemand
pm = dynamic

cranked max_children up

; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes when pm is set to 'dynamic' or 'ondemand'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
; CGI. The below defaults are based on a server without much resources. Don't
; forget to tweak pm.* to fit your needs.
; Note: Used when pm is set to 'static', 'dynamic' or 'ondemand'
; Note: This value is mandatory.
pm.max_children = 150

; The number of child processes created on startup.
; Note: Used only when pm is set to 'dynamic'
; Default Value: (min_spare_servers + max_spare_servers) / 2
pm.start_servers = 3

; The desired minimum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.min_spare_servers = 3

; The desired maximum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.max_spare_servers = 5

and just like magic the UI is responsive again.

(37 dockers, 3 vms, 1.000 processes, i9-12900K cpu with 128GB memory of which 12GB used (rest goes to linux buffer), nvme exclusive shares)

I did try that, but after an reboot it fall back to default. You may need a script or something to make your changes after a reboot.

13 hours ago, uCoreX said:

I did try that, but after an reboot it fall back to default. You may need a script or something to make your changes after a reboot.

I just noticed that as well. Do you have susch script?

43 minutes ago, MobileDude said:

I just noticed that as well. Do you have susch script?

Still same problem with the latest unraid v. 7.2.1.



Script by @bmartino1
https://forums.unraid.net/topic/194245-pool-www-server-reached-max_children-setting-50-consider-raising-it/#comment-1585016

I haven't tested it.

Edited November 20, 2025Nov 20 by uCoreX

Unraid 7.2.2
[WARNING] [pool www] server reached max_children setting (50), consider raising it

GPU statistics plugin removed, Warning still shows up

I have the same issue like everyone above on 7.2.2 without GPU statistics plugin installed. I didn't know what the issue was before because the server was fine with only the array started and mounted without cache - this was part of my troubleshooting and concluded that something is wrong with my cache. So I rebuilt my cache pool, reformatted ZFS, and installed just one (1) Docker just to see how things run, Plex, so my kids have access to their shows. After leaving it overnight for Plex to do its metadata updates, the server is now sluggish with the same OP error.

Edited December 11, 2025Dec 11 by spacer00ster

On 11/14/2025 at 11:30 PM, Samsonight said:

Still an issue in v7.2.0, switched to dynamic, love how we are using static values on a scalable platform...

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;             pm.max_spawn_rate    - the maximum number of rate to spawn child
;                                    processes at once.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
; limetech - let's use ondemand
;pm = dynamic
;pm = ondemand
pm = dynamic

cranked max_children up

; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes when pm is set to 'dynamic' or 'ondemand'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
; Equivalent to the PHP_FCGI_CHILDREN environment variable in the original PHP
; CGI. The below defaults are based on a server without much resources. Don't
; forget to tweak pm.* to fit your needs.
; Note: Used when pm is set to 'static', 'dynamic' or 'ondemand'
; Note: This value is mandatory.
pm.max_children = 150

; The number of child processes created on startup.
; Note: Used only when pm is set to 'dynamic'
; Default Value: (min_spare_servers + max_spare_servers) / 2
pm.start_servers = 3

; The desired minimum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.min_spare_servers = 3

; The desired maximum number of idle server processes.
; Note: Used only when pm is set to 'dynamic'
; Note: Mandatory when pm is set to 'dynamic'
pm.max_spare_servers = 5

and just like magic the UI is responsive again.

(37 dockers, 3 vms, 1.000 processes, i9-12900K cpu with 128GB memory of which 12GB used (rest goes to linux buffer), nvme exclusive shares)

Mine is set to ondemand per default. Ondemand and dynamic behave similar except that ondeman doesn't have a child process if not needed while dynamic keep some children process alive even idle. The pm.max_children is a static value, there's no way to put a dynamic value here.

But, if it's overwritten at boot, it means there's a process at boot that write that value. This could be edited to allow for a calculated way of setting the max children based on ram. There's many calculation available to do that.

As for your script, if it's a boot, you can create a userscript that run at array start (or at boot or whatever you desire) with this:

sed -i "s/pm.max_children = 50/pm.max_children = 150/" /etc/php-fpm.d/www.conf

If you also want to change to dynamic, you can put this also

sed -i "s/pm = ondemand/pm = dynamic/" /etc/php-fpm.d/www.conf

Edited December 15, 2025Dec 15 by Nodiaque

2 minutes ago, Nodiaque said:

Mine is set to ondemand per default. Ondemand and dynamic behave similar except that ondeman doesn't have a child process if not needed while dynamic keep some children process alive even idle. The pm.max_children is a static value, there's no way to put a dynamic value here.

But, if it's overwritten at boot, it means there's a process at boot that write that value. This could be edited to allow for a calculated way of setting the max children based on ram. There's many calculation available to do that.

I'm quite certain we intend Limetech to fix their presented issues from 2018 instead of us duct-taping half of the whole product... 😉 and works on my comp

Edited December 15, 2025Dec 15 by Samsonight
clarification

All I did is provide the script people were asking some reply ago, like here https://forums.unraid.net/topic/103947-691-server-reached-max_children-setting-50/page/2/#findComment-1591393 and here https://forums.unraid.net/topic/103947-691-server-reached-max_children-setting-50/page/2/#findComment-1591499

And also, all that need to be done is to fix the process that create that file, which is something limesoft need to do since it's in the boot process. I only state what's going on.

Edited December 15, 2025Dec 15 by Nodiaque

1 minute ago, Nodiaque said:

All I did is provide the script people were asking some reply ago, like here https://forums.unraid.net/topic/103947-691-server-reached-max_children-setting-50/page/2/#findComment-1591393 and here https://forums.unraid.net/topic/103947-691-server-reached-max_children-setting-50/page/2/#findComment-1591499

Then quote them, not me ❤️two completely different things.

First part is about the fact you said it's static, I simply say that mine is ondemand and that ondemand or dynamic won't change the problem with maximum children.

Second part is about the script. So that's why you got quoted