Issue high cpu usage plesk 18.0.50 - Ubuntu 20.04.5 LTS

[xonex]

Server operating system version

Ubuntu 20.04.5 LTS

Plesk version and microupdate number

18.0.50

Good morning everyone,

I write on this forum because since we moved the sites to a new server from a ubuntu 14 to ubuntu 20, the server has a lot of slowdowns. The CPU has high usage. We can't understand why with old server and with old plesk.

The difference I can think of on these sites is that we installed wordfence and in the old server it wasn't there.

 

[Peter Debik]

A first step to narrow this down can be to look at # top or # htop to see which processes consume a lot of cpu time.

 

[xonex]

thanks for your answer. Already done and sometimes many PHP-FPM processes are accumulated together with different sites.

 

[trialotto]

thanks for your answer. Already done and sometimes many PHP-FPM processes are accumulated together with different sites.

That is normal, at least when the sites are being "used" by external processes (request to the Apache web server, for instance) or internal processes (from Plesk).

Plesk is configured to spin up several PHP processes, in order to create some efficiency when serving web requests.

However, some (or most) of these web requests can be "dubious" - from improper requests to bad to very malicious.

These two things - Plesk normal activity and dubious activaties - should be distinguished ...... and that cannot be seen with top or htop commands.

You should essentially reduce the dubious activities by using the Web Application Firewall (WAF) and Fail2Ban : this will reduce the PHP loads.

In addition, you could reduce any type of activity by adding Nginx as a reverse proxy - most requests (bad or good) can be dealt with by Nginx (and will not reach the Apache web server) and some requests (bad or malicious) can be kept out of the system : this will reduce the PHP loads considerably.

Naturally, I am telling the simple story, there is much more to it.

But Plesk is actually quite simple, you can add the WAF, Fail2Ban and Nginx with a couple of clicks in the dashboard.

Please try, if you did not do that already!

Kind regards....

 

[xonex]

I've already set up the modsecurity firewall, fail2ban and set up the reverse proxy with ngix.

Is it possible that there is some cron job doing checks on all sites? On plesk, however, I have already reduced the cron processes to avoid continuous slowdowns.

Are there any other "hidden" ones?

 

[trialotto]

I've already set up the modsecurity firewall, fail2ban and set up the reverse proxy with ngix.

Is it possible that there is some cron job doing checks on all sites? On plesk, however, I have already reduced the cron processes to avoid continuous slowdowns.

Are there any other "hidden" ones?

@xonex

You are now focusing on "cronjobs" even though the answer is often more obvious.

You should first inspect the logs, especially modsec_auth.log ........ it would not surprise me if your sites get bombarded with bad requests.

Just inspect the logs first and work from there!

Kind regards....

 

[mow]

A first step to narrow this down can be to look at # top or # htop to see which processes consume a lot of cpu time.

And the next step is to install lm-sensors to check whether the temperatures are normal.

 

[trialotto]

And the next step is to install lm-sensors to check whether the temperatures are normal.

Or just check the workload that is created as a result of the installation of wordfence that will probably pick out thousands of brute-force attempts on WP?

Thousands, per day, per WP instance!

Or just check whether the hosting provider has provided an old rubbish server, as opposed to the promised "new and clean server".

It happens

 

[mow]

Or just check the workload that is created as a result of the installation of wordfence that will probably pick out thousands of brute-force attempts on WP?

If the load with wordfence is higher than without, then wordfence is a problem, not a solution.

 

[trialotto]

If the load with wordfence is higher than without, then wordfence is a problem, not a solution.

@mow

I had to read that line multiple times but yes, Wordfence can be a pain-in-the-***.

In essence, it - and similar WP plugins - are always a problem, by default.

Most of these plugins are trying to combat things that should not happen on or be a burden for Apache ...... but they combat on the level of Apache.

So, yes, any usage of WP Rocket, Wordfence, some other plugins or even a combination of them can really kill the web server, certainly when under attack.

And in some cases, scripts are just scanning sites to identify the presence of these plugins, since bomdarding the web server with simple (often DDoS alike) attacks can open the door ..... for other funny stuff.

Long story short, you are absolutely right !