tnoetz01

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.

@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.

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.

Just an update here in case anybody stumbles on this... the drive eventually failed (a bunch of Reallocated sector count errors), and WD replaced it via RMA. So apparently Unraid can notice issues before SMART reports start failing, and write errors can show up prior to any timeouts, SMART errors, etc.

Yeah, I was stumped, too... for the little it's worth, ChatGPT seemed to think it was either a transient SATA data connectivity or power draw issue (which was why swapped out data cables, switched the parity drive to the other SATA port, and I put the HDD on its own dedicated power cable). None of that helped, unfortunately. I'm like a week past the retailer return window. Hoping I don't have to go through WD for a replacement. And I'm reluctant to even try given the SMART status.

I don't have another disk at this point... I have 2 more coming from WD, but they're back-ordered and won't ship for a while.

I have a bit of a weird situation that's got me stumped. About a month ago I built a server using an Optiplex 7050 SFF MB (moved to a midtower case) and two new 10TB WD Red Plus drives (in addition to a 512gb m.2 SSD for cache). A couple days ago the parity drive showed some write errors and disabled itself. I ran an extended SMART test and there were no issues. Even after moving the parity drive to its own power cable and new data cable (also moved it to the primary port), the parity build fails about 2 hours in. Any ideas here? Attaching the diagnostic zip. Can attach the SMART report as well if needed (though not sure if I need to scrub anything from that) server1-diagnostics-20251202-1123.zip