Issue Daily Maintenance Script Spawns Off A Bunch Of PHP-FPM processes Leading To Huge Load Spike

[Ladylinux]

Server operating system version

Debian 12

Plesk version and microupdate number

18.0.62

Hi,

I have removed log browser , monitoring , awstats/webalizer and end user logging.

Painstakingly running each task at once does not duplicate the issue. At sometime during the Maintenance task run load for a brief while spikes to around 60 and I note a ton of these processes running. (100's)

/usr/bin/sw-engine -c /opt/psa/admin/conf/php.ini /opt/psa/admin/sbin/collectdmng-handler

Then panel.log shows this

[2024-07-31 00:17:33.320] 11649:66a8f5fd4df5e ERR [panel] DB query failed:
"SET sql_mode = ''"

Error: SQLSTATE[08004] [1040] Too many connections
[2024-07-31 00:17:33.487] 11559:66a8f5fd402f6 ERR [panel] DB query failed:
"SET sql_mode = ''"

Error: SQLSTATE[08004] [1040] Too many connections
[2024-07-31 00:17:33.775] 11559:66a8f5fd402f6 ERR [panel] DB query failed: SQLSTATE[08004] [1040] Too many connections:
0: /opt/psa/admin/plib/Db/Adapter/Pdo/Mysql.php:79
Db_Adapter_Pdo_Mysql->query(string 'SET sql_mode = ''')
1: /opt/psa/admin/plib/CommonPanel/Application/Abstract.php:113
CommonPanel_Application_Abstract::initDbAdapter()
2: /opt/psa/admin/plib/api-common/AbstractCu.php:1524
AbstractCu::initDb()
3: /opt/psa/admin/plib/api-common/AbstractCu.php:1548
AbstractCu::initCLI()
4: /opt/psa/admin/plib/api-common/cuApp.php:22
cuApp->__construct()
5: /opt/psa/admin/plib/scripts/collectdmng_handler.php:140
require_once(string '/opt/psa/admin/plib/scripts/collectdmng_handler.php')
6: /opt/psa/admin/sbin/collectdmng-handler:3

Mind you this server has a remote sql db for users but the plesk db for the panel is local and these are related to the local db.

Also this is a relatively new server (AWS) with 2CPU's and 8GB of memory. Its stock Debian 12 and I enabled a swapfile since AWS does not

Yes I can and will adjust the local mariadb to allow more connections. But I am seriously concerned about just why the heck would a simple daily maintenance run go out of control like this.

So question is ?? What set of tasks is this so I can script excluding them and running at a different time to see if

I can't add CPU's or memory as this replaced a Cpanel (Boo Hiss) server with the same specs that for years has had no spikes.

This loading I could ignore except AWS as we are using it has a daily CPU/Memory burst credit that we really don't want use up everyday.

Thanks!!

LadyLinux

PS: We have had a Debian 11 Plesk server with less sites that does that have this issue. Software is identical except server version. Actually that server has log browser , monitoring , stats and user logging enabled with out any issues. I think this is how many sites we have hosted but its only about 60 at the moment. Not even the 100 plus on Cpanel (Boo Hiss) that still need to be migrated.

 

[Ladylinux]

Oh,

What set of tasks is this so I can script excluding them and running at a different time to see if the issue goes away.

Meant to say the above

LadyLinux

 

[Ladylinux]

Hi,

OK I have found what I am pretty sure is the issue

When changes are made to subscriptions load rockets up. Its more about the quantity of subscriptions as it seems to be an issue when you get past 50 or so subscriptions.

Plesk seems to spawn off processes to match the subscription count. Since the server only has 8GB memory these PHP processes use up all the memory and then we get to the dreaded swap which causes load.

Mind you that while we have a LOT of subscriptions server load ONLY goes past 1 a couple times a day and even at that for a few seconds.

But when we make any changes to subscriptions load goes as high as 100 but just for less than a minute.

I did re-script the daily maintenance job to run tasks ten at a time or less and one by one with waits strategically placed.

The script runs without load spikes but to be honest I really had to make an educated guess at this.

Daily Maintenance stuff is all encrypted PHP which is just a black hole since there is no real documentation i could find that details what each job is doing.

Thanks!!

LadyLinux

PS: I know this write up is bogus but it was the best I could do considering the silence from Plesk on this issue which I think affects more than just myself.