• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Huge load average, uninterruptible state

> After the issue, I tried using all possible combinations of php handlers with php versions and even tried to make nginx as primary server but in every combination I have been facing same issue.

So your server is non-functional right now?
yes in my current settings server is non functional. As soon as i turn on my server or turn off the maintenance mode the cpu reaches 100% within 2-5 minutes
 
Fixed in Plesk 18.0.35:

Plesk now preserves the following custom settings of the [php-fpm-pool-settings] section in additional php.ini directives: chroot, clear_env, decorate_workers_output. (PPPM-12666)
The official configuration of WordPress permalinks now works if nginx and PHP-FPM are used in tandem. (PPPM-12817)
If PHP-FPM is served by nginx in Apache+nginx hosting, custom error documents for PHP scripts now work. (PPPM-12815)
An add-on plan with disabled PHP settings can no longer affect the PHP settings of a subscription created based on the plan. (PPPM-12864)
 
Last edited:
Hello guys @Dave W @john0001
I am still facing cpu spike issue even after the updating to 18.0.35.
Do I need to change any other configuration after increasing innodb_log_file_size as I have increased that. I kind of feel like it's some kind of bottleneck between mysql and php. Mysql processes are consumed around 20-24% and remaining 70% occupied by php-fpm processes.
 
It looks like your site is just getting too much traffic. Could be bot/invalid traffic, likely is. Inno db log size doesn't affect performance consistent with what you are seeing.
 
It looks like your site is just getting too much traffic. Could be bot/invalid traffic, likely is. Inno db log size doesn't affect performance consistent with what you are seeing.
It should be a bug in plesk. Many people are saying the same that after 18.0.33 update the site just got slow.
I am not able to keep site live for more than a month, I want to use plesk but this issue/bug is making me think about migrating.
Please help.
Just now checked here bug
 
It should be a bug in plesk. Many people are saying the same that after 18.0.33 update the site just got slow.
I am not able to keep site live for more than a month, I want to use plesk but this issue/bug is making me think about migrating.
Please help.
Just now checked here bug
What "bug" are other people reporting? The thread list you linked doesn't have anyone with similar issues. I've gone through .35 extensively and run .34 on production. There are no performance issues that I know of.
 
No bug here either. It's definitely an issue with the site(s).

@omkarmore What steps have you taken to analyze your scripts, e.g. what exactly they are doing and where they are spending their cpu time?
 
No bug here either. It's definitely an issue with the site(s).

@omkarmore What steps have you taken to analyze your scripts, e.g. what exactly they are doing and where they are spending their cpu time?
It's the php-fpm and mysql processes that accumulate cpu resources.
I tried plesk repair all
I tried to increase hardware configuration.
I tried to setup a fresh plesk install and migrate the site back but same issue persists.
 
Because it is the same site. It has nothing to do with the services. PHP is not a Plesk invention, neither is the PHP-FPM service. The problem is a script that is consuming a lot of cpu power. You'll for sure find entries in your access_log or error_log that point you to the right source.
 
Because it is the same site. It has nothing to do with the services. PHP is not a Plesk invention, neither is the PHP-FPM service. The problem is a script that is consuming a lot of cpu power. You'll for sure find entries in your access_log or error_log that point you to the right source.
Yes, you are right, I read somewhere that some scheduled cron jobs might be causing the cpu power consumption. But how can I check which scripts are causing that.
I am getting all of this over the error log (70007) the timeout specified has expired.
 
You also have an access log. You need to follow what the website is doing.
I am getting following entries during the time cpu usage is high:

127.0.0.1 - - [27/Apr/2021:00:51:01 +0530] "POST /modules/monitoring/public/index.php/EloR
CGx39312US-m3QvZVQfFDxCxgRRUe5BVV-W4/query HTTP/1.1" 200 116 "-" "Go-http-client/1.1" "-"'
/modules/monitoring/public/index.php/EloRCGx39312US-m3QvZVQfFDxCxgRRUe5BVV-W4/query' '' '/
opt/psa/admin/htdocs'
127.0.0.1 - - [27/Apr/2021:00:51:01 +0530] "POST /modules/monitoring/public/index.php/EloR
CGx39312US-m3QvZVQfFDxCxgRRUe5BVV-W4/query HTTP/1.1" 200 123 "-" "Go-http-client/1.1" "-"'
/modules/monitoring/public/index.php/EloRCGx39312US-m3QvZVQfFDxCxgRRUe5BVV-W4/query' '' '/
opt/psa/admin/htdocs'
127.0.0.1 - - [27/Apr/2021:00:51:03 +0530] "POST /modules/monitoring/public/index.php/EloR
CGx39312US-m3QvZVQfFDxCxgRRUe5BVV-W4/query HTTP/1.1" 200 117 "-" "Go-http-client/1.1" "-"'
/modules/monitoring/public/index.php/EloRCGx39312US-m3QvZVQfFDxCxgRRUe5BVV-W4/query' '' '/
opt/psa/admin/htdocs'
127.0.0.1 - - [27/Apr/2021:00:51:09 +0530] "POST /modules/monitoring/public/index.php/EloR
CGx39312US-m3QvZVQfFDxCxgRRUe5BVV-W4/query HTTP/1.1" 200 124 "-" "Go-http-client/1.1" "-"'
/modules/monitoring/public/index.php/EloRCGx39312US-m3QvZVQfFDxCxgRRUe5BVV-W4/query' '' '/
opt/psa/admin/htdocs'
 
You can try to exclude the bot with this section that you can insert in the top lines of your .htaccess file:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} (Go-http-client) [NC]
RewriteRule .* - [F]
 
You can try to exclude the bot with this section that you can insert in the top lines of your .htaccess file:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} (Go-http-client) [NC]
RewriteRule .* - [F]
I tried using it but no luck.
Just in case can deleting access log cause any such issues, as I may have by mistakenly deleted the access log from filemanager. I don't see any access log present in logs folder. I have access ssl log present.
The one I shared above was present at location /var/log/plesk/httpsd_access_log
 
I don't know why you would delete the error log, but no, it doesn't cause the issue you're seeing.
 
It's just under 100mb.
I tried optimizing database.
It sounds to me like you just started getting more traffic that coincided with a Plesk update. If you don't believe that is the case, I'd look at hiring an external developer/sysadmin to take a look.
 
Back
Top