How do I fix this log message? Started appearing recently and not sure what is causing it.

Nov 17 14:53:58 OrbitalHub php-fpm[16478]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

...

i need to find the forum post and script...

Edited November 19, 2025Nov 19 by bmartino1

please post a unraid diagnositc file... and list what dockers your using...  as I've found this to be a issues in fastcgi and hoe emhttp implements its php code for some tasks...

user scritp trun the script in the above post... Oh hey its use from the past....

so gives us somthign your doing to go off of and we can help...

from the picture of the log... what i'm seeing its becasue your tryign to use teh appdata backup sytem and somthing may be misconfigured. (didnt' run in a set amount of time)
simalr to unable to use teh webui when you hit apply on unraid as it docker pulls the image and settings...

your doing to much at once on the system...

Hi,

Been having this warning messages for a some time now. Not sure when and how.

I can just stay on the MAIN page and wait few minutes and the is got the warning, wait again some minutes and again.

Nov 20 07:14:38 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Nov 20 07:16:18 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Nov 20 07:23:54 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Nov 20 17:21:03 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Nov 20 17:25:32 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Nov 20 17:29:35 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Running this command to see how many php-fpm i'm running:

root@Galactica:~# ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }' | grep php-fpm

8.14 Mb php-fpm: pool www

7.67 Mb php-fpm: pool www

7.57 Mb php-fpm: pool www

7.47 Mb php-fpm: pool www

7.37 Mb php-fpm: pool www

7.26 Mb php-fpm: pool www

7.20 Mb php-fpm: pool www

6.27 Mb php-fpm: master process (/etc/php-fpm.conf)

0.69 Mb grep php-fpm

Starting up only NGNIX, all good, then starting up Homepage. Still good, but when i enter Tautulli, see bellow. And same with UptimeKuma . Not sure why those two containers trigger so many php-fpm requests.
But i'm not 100% .



root@Galactica:~# ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }' | grep php-fpm

7.83 Mb php-fpm: pool www

7.50 Mb php-fpm: pool www

7.49 Mb php-fpm: pool www

7.48 Mb php-fpm: pool www

7.43 Mb php-fpm: pool www

7.39 Mb php-fpm: pool www

7.27 Mb php-fpm: pool www

7.20 Mb php-fpm: pool www

7.19 Mb php-fpm: pool www

7.19 Mb php-fpm: pool www

6.46 Mb php-fpm: pool www

6.46 Mb php-fpm: pool www

6.46 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.39 Mb php-fpm: pool www

6.27 Mb php-fpm: master process (/etc/php-fpm.conf)

0.69 Mb grep php-fpm

---

Nov 20 17:52:05 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

Edited November 20, 2025Nov 20 by uCoreX

I give up, I have turn off all my containers, the only one i'm running now is Plex.
And still have this warning. I was gone for 1 hour now and just updated the DOCKER page.

Nov 20 20:48:42 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

2 hours ago, uCoreX said:

I give up, I have turn off all my containers, the only one i'm running now is Plex.
And still have this warning. I was gone for 1 hour now and just updated the DOCKER page.

Nov 20 20:48:42 Galactica php-fpm[8509]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

did you automate app data backups?

depending on how you set this up this plugin is capable of hiting the fascgi max childs...
could also be a misconfiguration on how your backingup a docker.

this is a example as stated inteh other forum you have to find teh memory leak that cosund be anythign form teh dashboard script on emhttp to a tab left open over night to a docker or other hardware failure in ram...
teh 50 to 200 is a temp fix to allo it to run . and default its 50 personaly if i'm doing AI tasok or heavey automation and scripting liek ansible i woudl want this to be higher...

The point, is your doing to much on th sytem if your hitting this...

Edited November 20, 2025Nov 20 by bmartino1

Can you perhaps help me narrow it down then if you think I am doing to much on my server to get this?

My erver has not only improved thrice hold since I bought it but I've also learnt what to or not to do, have 120TB storage, I would appreciate a starting point unless you're just nostradamus.

17 hours ago, paradox.actual said:

Can you perhaps help me narrow it down then if you think I am doing to much on my server to get this?

My erver has not only improved thrice hold since I bought it but I've also learnt what to or not to do, have 120TB storage, I would appreciate a starting point unless you're just nostradamus.

still need a sylog something to go in and check it towards... Please post unraid diagnostic...

unfortunately i'm not near the server until tomorrow.

Noticed this warning appearing in my log since 7.2 update. I am wondering if this is related.

On 11/26/2025 at 7:23 PM, jfoxwoosh said:

Noticed this warning appearing in my log since 7.2 update. I am wondering if this is related.

no, may things use fastcgi. this telms me you have a script, task or somthign runing that hit the php mzx child limit. usualy becaue somethigns ran along side somthign elses or a memeory leak. I've seen this more common with appdata backup and misconfiruation with backups as it takes a while to backup a docker...

some scirpt and docker comunication require a highers fastcgi limit. thus the script to rasie the limit... I'm just warnnign that rasing the limit is not the solution you need to find the combination or use onthe server that is hitting the limit...

@bmartino1 , thanks for the reply. My appdata backup is configured to run manually, so I can rule that out for now.

I have noticed, the timestamp of this php-fpm warning appearing lining up with me simply login into the webui with a browser.

Although not always, but it has a high chance of the warning appearing when I use my iPhone's Firefox browser and Windows 11 Edge browser to access the server's webui.

I am now testing using the Firefox browser on Linux Mint laptop and to see if this will happen or not.

For the past two weeks, I have been refraining myself from using mobile phone browser and Windows 11 Edge browser to access server's webui, and no trace of php-fpm warning in syslog.

During this period, I have only used my Linux Mint laptop and VM's firefox browser to access the webui.

My next experiment will be using Linux Mint's flatpak Mircosoft Edge browser and see the warning can be reproduced.

I'm still investigating what may be causing this and at best I'm getting some weird stuff with those that use the unraid connect and it's due to how the API is being redeveloped and changed, but the API shouldn't be causing these errors to this degree.

I'm not sold that. It's the unraid connect plug-in if you use that but wanted to throw that out there as a potential problem area

I'll try it without that plugin for a bit see if it pops up again. It's about every 10-15 minutes.

Upgraded to version 7.3.0 Beta 1 and still the same warnings as it was on previous version.

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

Edited March 22Mar 22 by uCoreX

Tried without that plugin also and still getting it.

13 hours ago, paradox.actual said:

I'll try it without that plugin for a bit see if it pops up again. It's about every 10-15 minutes.

10 hours ago, uCoreX said:

Upgraded to version 7.3.0 Beta 1 and still the same warnings as it was on previous version.

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

https://forums.unraid.net/topic/178033-bmartino1-user-scripts/page/2/#findComment-1598908

...

then find the memory leak here is how you can...

For what it's worth, the biggest driver of high php-pfm children for me seems to be browsing shares via the Unraid GUI. That said, those do clean up, so it's a bit unclear if/why this would actually cause an issue, given that they typically drop back down within a few seconds.

Steps to reproduce:

0) If you're not already at a low max-children count, you may need to restart your Unraid Server to observe this happening cleanly...

1) From the unraid terminal (or SSH) run:

watch -n 0.5 '

date

echo -n "php-fpm total: "; pgrep -c php-fpm

echo -n "php-fpm workers: "; ps -ef | grep "php-fpm: pool www" | grep -v grep | wc -l

echo -n "file_manager: "; ps -ef | grep "webGui/nchan/file_manager" | grep -v grep | wc -l

'

2) In a separate window, browse a share from the Unraid GUI

• (lots of sub-files may make a difference, a bit unclear)

3) Observe that your workers start to get high... for me, it seems like it hits ~35-40 right when opening a share, but drops back to 1 within a few seconds.

17 hours ago, tnoetz01 said:

For what it's worth, the biggest driver of high php-pfm children for me seems to be browsing shares via the Unraid GUI. That said, those do clean up, so it's a bit unclear if/why this would actually cause an issue, given that they typically drop back down within a few seconds.

Steps to reproduce:

0) If you're not already at a low max-children count, you may need to restart your Unraid Server to observe this happening cleanly...

1) From the unraid terminal (or SSH) run:

watch -n 0.5 '

date

echo -n "php-fpm total: "; pgrep -c php-fpm

echo -n "php-fpm workers: "; ps -ef | grep "php-fpm: pool www" | grep -v grep | wc -l

echo -n "file_manager: "; ps -ef | grep "webGui/nchan/file_manager" | grep -v grep | wc -l

'

2) In a separate window, browse a share from the Unraid GUI

• (lots of sub-files may make a difference, a bit unclear)

3) Observe that your workers start to get high... for me, it seems like it hits ~35-40 right when opening a share, but drops back to 1 within a few seconds.

Untill some one can make reproduceable stpes and submit a bug report....

The clean up is apart of the Dynamix GUI system plugin that was integrated into unraid. the web gui does handle qute a bit of php and fastcgi calls to move dispal and run teh termianl caomnds that would be done when using. I'm not suprsed to see a 5 or more jump...

Users getting and hitting the child max have some form of memory leak due to a php and dead fast cgi calls that the task never got the signal to die and became a zombie pid...
there are many features, applications, dockers, scripts, that can cause the host's FastCGI PID to not die as its still running a task.
Those are memory leaks. As something didn't die and the initial run was stopped before a cleanup or killing of the task.

There is no 1 thing that causes the pid to become stale and fill up past 50

its not reproducible, which is the problem. Some issues in the past were the update script for the unraid dashboard (php fastcgi to collect stats and display...), and it was more prone to populate due to the unraid gui dashboard being open somewhere overnight.

I can only recommend running the https://forums.unraid.net/topic/178033-bmartino1-user-scripts/page/2/#findComment-1598908
which has the ability to tell you where and potentially fix once activated at boot due to how unraid handles php and fastcgi.

@bmartino1 - Well, I guess that's my point. Getting that warning isn't, in and of itself, indicative of a memory leak. If you have max children set to the default (50), you're likely to encounter that through normal use, e.g. browsing through a few shares and/or using a couple of plugins. In normal operation, after a few seconds the idle workers get cleaned up and the total number drops back below 50.

It's only a memory leak if the cleanup never happens.

I've had a few instances where my server has hung and the GUI becomes unresponsive, but because the logs only show the workers going above the max but don't show whether or not they then went back down below the max, it's unclear if this is actually related or not.

Given that, I've built my own logging script to log a bunch of system metrics every minute, including the number of PHP-FPM workers (and their ages).

Hopefully next time there's a GUI hang I'll be able to verify whether the workers themselves actually haven't been cleaned up.

Quick update here... just experienced another hang.

As I suspected, the server reached max_children warnings were a total red herring. The real issue was that the flash drive was disconnecting.

I only caught this because I had set up a truly remote syslog server (on Google Cloud for free) and configured the local syslog to send logs there. Prior to doing that, I was writing the syslogs to the flash drive (like most people do), which obviously doesn't work when the flash drive disconnects.

It's a bit unclear to me why this is happened, but it may have been because, while my Flash Drive is USB 2.0, I had it connected to a USB 3.0 port. I've since moved it to a 2.0 port, so hopefully this doesn't reoccur, but if it does I'll update this thread.

My biggest suggestion for folks who are experiencing these hangs is to set up a remote syslog server and send your syslogs there. This ensures you get every error message right up until the point that the syslog service itself stops working. In my case, syslog service continued to send messages to the remote server even after the GUI hang, so I could see clearly what was happening.