Issue PHP-FPM - Sleeping

[sjdean]

Server operating system version

Ubuntu 20.04

Plesk version and microupdate number

18.0.51

Seem to have a few problems where it appears that despite all websites being set to their own Dedicated PHP-FPM application served by Apache, when one of the sites locks, it seems to lock all the other websites and we get

Error: upstream timed out (110: Connection timed out) while SSL handshaking to upstream.

This issue occurs in the logs of several of our domains at the same time, I am unable to find a direct root cause. Closest I have found is that one site uses a GuzzleHttp/Curl/HttpClient to read from a remote API, but it appears that sometimes, that connection times out and the PHP-FPM module stays open and sleeping in the background such that we get the error to increase the pm_max_children - which already sits at 100 for the affected website.

Never had this problem on a previous host (Azure App Service).

So I guess how can we prevent PHP-FPM from "Sleeping" in the background and time out safely and correctly in the event of a script failure so that it doesn't lock resources elsewhere?

 

[Peter Debik]

It is not likely that one failing dedicated PHP process can influence others. The symptom can be that no sites are responding, but the cause could be something different. To find out more I suggest to investigate what other PHP-FPM processes are doing in the situation when sites are failing. Are they really stuck? Or are they waiting on something, e.g. name resolution?

 

[sjdean]

It looks like the first issue we had was a high CPU usage. Unfortunately atop is not automatically installed out of the box, and we don't get any notifiations anywhere as to the offending process(es) which would be useful.

And don't even get me started on how the free version of the Monitor 360 doesn't give any CPU/Memory monitoring of selected websites like the inbuilt monitoring which can no longer be accessed after enabling Monitor 360.

We've enabled atop and will need to monitor further.

However the second issue still exists in multiple PHP-FPM applications being spawned when GuzzleHttp/Curl is unable to connect to a remote API. I realise this is more PHP orientated than Plesk, but alas, I'm unable to locate an appropriate setting to resolve this