• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Issue high cpu usage plesk 18.0.50 - Ubuntu 20.04.5 LTS

xonex

New Pleskian
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.
 
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.
 
thanks for your answer. Already done and sometimes many PHP-FPM processes are accumulated together with different sites.
 
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....
 
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?
 
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....
 
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 ;)
 
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.
 
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. o_O

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 !
 
Back
Top