Gemini has the suggestion below. If it doesn't help, upgrading to SMF 2.1 might help.
You could ask about the problem here
https://www.simplemachines.org/community/index.php?board=147.0It sounds like a solvable problem.
<quote from Gemini>
The solution is to configure the PHP-FPM Pool (this is the most likely software they are using) to automatically manage its own processes.
The owner needs to find their PHP-FPM configuration file (it's often called
www.conf or something similar inside the PHP-FPM pool.d directory).
Inside that file, they should look for these settings and change them:
Set the Process Manager to dynamic or ondemand.
The dynamic setting is the most common. It lets the server "spin up" new processes when busy and "spin down" idle processes when quiet.
This prevents the "too many processes" buildup.
The setting will look like this: pm = dynamic
Set Server Limits.
These settings tell the dynamic manager what to do. A good starting point would be:
pm.max_children = 20 (The absolute max processes allowed. 20 is a safe number, but this depends on server RAM.)
pm.start_servers = 5 (Start with 5 processes ready to go.)
pm.min_spare_servers = 2 (Always keep at least 2 processes idle and waiting.)
pm.max_spare_servers = 10 (Don't keep more than 10 idle processes waiting.)
Set a "Process Expiry." (This is the most critical fix for them)
This is the most important setting for their specific problem. It tells PHP-FPM to automatically kill and restart a process after it has handled a certain number of requests.
This is a failsafe that prevents buggy scripts or memory leaks from creating "zombie" processes that never die. This is exactly what the owner is seeing.
The setting is: pm.max_requests = 500
This means "After any single process has handled 500 web page requests, kill it and start a fresh, clean one." This automatically "cleans up" the system without any manual work.
By making these changes (and restarting the PHP-FPM service), the server will begin to manage itself correctly, and the "Service Unavailable" errors will very likely disappear permanently.
</>
