PHP-fpm & high load

hello all,

I run a VM with Debian GNU/Linux 10 under ProxMox, with Virtualmin with 8 cores and 16gb ram.
This vm has high load, always more than 70-80%, with only 2 wordpress sites…

my /etc/php/7.4/fpm/pool.d/xxxxxxxx.conf settings are the same for two sites
pm = dynamic
pm.max_children = 60
pm.start_servers = 20
pm.min_spare_servers = 2
pm.max_spare_servers = 20

i suppose, there is a wrong setting but I cant find which…
can someone help me ?

Debian GNU/Linux 10
Linux 4.19.0-14-amd64 on x86_64

what cpu and real ram you have on proxmox machine, the real one

8 x Intel(R) Core™ i7-7700 CPU @ 3.60GHz (1 Socket)
32Gb Ram…

hi thats defo too much… on my demo server I have i7 too but very old gen… its i7-2760qm and running stress tests on all 8 cores within 12gb ram on 10 wp sites give me max 11% per core and about 4gb ram consumed.

I think its your php… official debian 10 does not have php 7.4 but php 7.3… I know that as I installed my test server two days ago from netinstall iso - means while install of fresh downloaded iso all packages except the core is downloaded and installed so no apt update command need it…

basically 7.3 not 7.4

If you share the output from ‘top’ it should point to the main culprit.

Seems mysql is being hammered pretty bad as well…

Either the sites are very busy, or you have some malicious scripts hanging around.
Check you WP sites, update everything, remove unused plugins and themes and check for .php files that aren’t supposed to be there.

@toreskev and @Paok1926 still if you look at this page: PHP - Debian Wiki I would not even consider this an issue to be asked here… To just give you an idea of versions here is an copy of the content from page mentioned above.

Release PHP version
Squeeze 6 5.3.3
Wheezy 7 5.4.45
Jessie 8 5.6.40
Stretch 9 7.0
Buster 10 7.3
unstable 7.4

To be fair, OP doesn’t state how the other PHP versions were installed, but if using f.ex. sury repo’s it’s really not a problem.
Virtualmin supplies docs on how to install it even.

That said, it’s not a Virtualmin issue. Like I said, most likely it’s due to some malicious and/or buggy code.

@toreskev exactly its not virtualmin issue - should be asked somewhere else like wordpress or php forums. anyway all issues are welcome here and speaking as web dev my self I do not think its something malicious running out there on him, its just he uses OS which can break with package installed - no one cares how he did install it - I was not saying anything about that and you pointed right. What I said to op and pointed clear was its risky business and I did not care what and how, I said his os should not run this version as this will and could lead to issues like he is experiencing.

Please you have to look at the issue as web dev, previous versions worked well as no issues mentioned, site is heavy loaded from his comment means site is popular - new package or upgrade of ppa or package caused issue suddenly - means nothing malicious but it could be but first I would look at log files instead of htop ot top - sql loaded badly does not mean something malicious, it could be his code is failing him.

Without log file and supplied informations - I would not even advice to him to have poo in morning after coffee and cigy. He runs os and that os does not support the version he want to run. Period = unstable = asking for troubles. if he must have php which is not supported by his os its all totally fine and cool - he might go with ubuntu os or any other beeding edge os

  • this advice is valid but on server which is stable - it would take him days to solve this even to me as devops it would take me couple of hours - and I can tell you - he would go no where. I like discussion about this but I think he would be better of on his os to use supported version of things he runs unless one know what he is doing…
  • my point is to save him from days of useless work, without results and halt any more pointless questions around, man we live once and time is important.
  • unstable = unstable = troubles

edit = debian unstable is stable we all know that but to use packages from debian unstable you have to install your system as unstable. Rest of os-es when they said unstable I end up in troubles… so that’s why unstable is bad even for me (running debian everywhere).

@toreskev also I do not care what you pointed out with - op said… I can read, got my eyes and speak languages - I know what “op” said - why would I even reply if I did not know what he said?

That was more of an observation pointing towards what you said about “unsupported” versions as such.

1 Like

I’ve been playing Whack-A-Mole with several Wordpress sites lately. A lot of plugins are putting their own scripts in that eat your site and server up. I’ve been getting rid of them one by one.

Wordpress used to do a decent job of regulating what developers could put in their apps, but lately it seems they’ve just given up even trying. It’s the wild, wild, west these days.

Even some old apps I’ve used for some time are doing it. Throwing in little scrips that constantly put up adverts to upgrade to pay version on your dashboard, advertise to others you use the plugin at your server’s expense, all kinds of junk like that.

It’s gotten completely out of hand.

1 Like

@Gomez_Adams this and many more other reasons forced me to gave up on once great blogging platform, I just write my blog in markdown and use bash to convert those to html, site on wp was fast on my server, don’t get me wrong but now its ultra fast plus markdown give out some capabilities like code sharing etc much much easy.


according to your advice, i updated everything, switched to php-fpm 7.3, disabled unused plugins…
the Yoast plugin was the most cpu consuming…

although the sites load faster, i still think that this load average is big…

can someone explain me the difference between the /etc/php/7.3/fpm/pool.d/www.conf
and the /etc/php/7.3/fpm/pool.d/155XXXXXXXXX.conf files ?

Temporarily disable the virtual server which belongs to


Then see if the load on cpu reduces dramatically.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.