EasyApache4 / php74 & 70 consuming 100% of all cores

[simonautomatic]

I'm having increasingly regular issues where my cloud server locks up, when serving php-based websites via EasyApache4

I have a couple of sites that are still stuck on php7.0 (And will take time to get them upgraded, as their developers need to figure out how to upgrade them), but most sites run on php7.4

Pretty much everything is running on wordpress. I have about 30 client sites running no the ser

I have the feeling that somehow the 7.0 sites can cause the entire server to lock up. The load becomes processor bound, and can easily spike up to a load average of 100 or more. But somehow it also feels like a memory leak, because the issues tend to escalate over time, until the only option that resolves it is to reboot the entire server (restarting apache and/or killing off all the ea-php processes doesn't help for more than a few moments)

Also, what is odd is that once one site has caused the load to rise, I tend to see all user accounts suddenly spawning more ea-php processes and putting further load on the server.

None of the sites are particularly heavy usage, so this looks very much like buggy behaviour somewhere in EasyApache.

I am not using php-fhm for any sites. I am using a fairly standard set of extensions including ruid

• CENTOS 7.8 kvm
• v88.0.12

runnning on a cloud machine (openstack) with 4 vcpus and 16GB RAM.

 

[RoseHosting]

I'm having increasingly regular issues where my cloud server locks up, when serving php-based websites via EasyApache4

I have a couple of sites that are still stuck on php7.0 (And will take time to get them upgraded, as their developers need to figure out how to upgrade them), but most sites run on php7.4

Pretty much everything is running on wordpress. I have about 30 client sites running no the ser

I have the feeling that somehow the 7.0 sites can cause the entire server to lock up. The load becomes processor bound, and can easily spike up to a load average of 100 or more. But somehow it also feels like a memory leak, because the issues tend to escalate over time, until the only option that resolves it is to reboot the entire server (restarting apache and/or killing off all the ea-php processes doesn't help for more than a few moments)

Also, what is odd is that once one site has caused the load to rise, I tend to see all user accounts suddenly spawning more ea-php processes and putting further load on the server.

None of the sites are particularly heavy usage, so this looks very much like buggy behaviour somewhere in EasyApache.

I am not using php-fhm for any sites. I am using a fairly standard set of extensions including ruid

• CENTOS 7.8 kvm
• v88.0.12

runnning on a cloud machine (openstack) with 4 vcpus and 16GB RAM.

Have you tried to tweak the PHP memory limits and the timeouts of the PHP 7.0 version if you think that version is making the load?

 

[cPanelLauren]

Really this wouldn't be a result of EasyApache it's users using PHP processes either legitimately and there's a misbehaving plugin or theme associated with your CMS site or maliciously. You'd want to identify the specific activity associated with those PHP processes. The following may also be helpful Tutorial - Troubleshooting high server loads on Linux servers

 

[dstana]

Check your server status

apachectl fullstatus

You've probably got a ton of bogus WordPress requests to wp-login.php and xmlrpc.php. I've also had problems with load on my servers while getting DDOS'd by the likes of Google, Microsoft, and anyone else who felt like crawling the server like crazy.

 

[simonautomatic]

Check your server status

apachectl fullstatus

You've probably got a ton of bogus WordPress requests to wp-login.php and xmlrpc.php. I've also had problems with load on my servers while getting DDOS'd by the likes of Google, Microsoft, and anyone else who felt like crawling the server like crazy.

You were absolutely right. I installed fail2ban with a wordpress filter and it's working a treat. Thank you so much!

 

[simonautomatic]

Have you tried to tweak the PHP memory limits and the timeouts of the PHP 7.0 version if you think that version is making the load?

Good suggestion but it didn't help. AS per below, it seems my issue was actually general hacking and spammy requests to wp-login.php and xmlrpc.php

 

[cPAdminsMichael]

Hi,
I recommend that you install CSF and add custom rules to block attacks on wp-login and xmlrpc
I have good experience adding these:

# XMLRPC
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*] "\w*(?:GET|POST) \/xmlrpc\.php.*" /))
{
  return ("WP XMLPRC Attack",$1,"XMLRPC","20","80,443,21,25,22,23","1");
}

# WP-LOGINS
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*] "\w*(?:GET|POST) \/wp-login\.php.*" /))
{
  return ("WP Login Attack",$1,"WPLOGIN","20","80,443,21,25,22,23","1");
}

# WP-ATTACHMENTID
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*\(?attachment_id=/))
{
  return ("WP Attachment Attack",$1,"WPATTACHMENTATTACK","20","80,443,21,25,22,23","1");
}

 

[dstana]

Hi,
I recommend that you install CSF and add custom rules to block attacks on wp-login and xmlrpc
I have good experience adding these:

# XMLRPC
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*] "\w*(?:GET|POST) \/xmlrpc\.php.*" /))
{
  return ("WP XMLPRC Attack",$1,"XMLRPC","20","80,443,21,25,22,23","1");
}

# WP-LOGINS
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*] "\w*(?:GET|POST) \/wp-login\.php.*" /))
{
  return ("WP Login Attack",$1,"WPLOGIN","20","80,443,21,25,22,23","1");
}

# WP-ATTACHMENTID
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /(\S+).*\(?attachment_id=/))
{
  return ("WP Attachment Attack",$1,"WPATTACHMENTATTACK","20","80,443,21,25,22,23","1");
}

Maybe I'm reading this wrong but it looks like these trigger for any activity. How do you allow valid traffic through with these rules?

 

[StefanPejcic]

Maybe I'm reading this wrong but it looks like these trigger for any activity. How do you allow valid traffic through with these rules?

Hi,

the "20" part dictates the number of failed logins needed for the IP to be blocked..
As in the example above, I recommend using at least 20 for wp-login.php - that's more than enough for any legitimate user..