• 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 php-fpm processes and mysql are maxing out server cpu

Server operating system version
Debian 10.13
Plesk version and microupdate number
18.0.59 #2
Hey friends.
Since 04:00 in the morning one of our servers started to have a very high load.
php-fpm pools and mysql ramp up to a serverload more than 200 ...
The only thing that helps is stopping mysql and killing php-fpm. Also we tried to stop different php versions, but nothing really helped.
Searched everywhere, all kind of logs, netstat and all that stuff...but nothing points us to the problem.
After digging the whole day we don't know what else to do, maybe some good advises?
 

Attachments

  • Screenshot 2024-05-06 193952.png
    Screenshot 2024-05-06 193952.png
    130.8 KB · Views: 11
A few hours everything was finde. since 06:30 it started again. Wenn we try
ss -tan state established | grep ":80\|:443" | awk '{print $4}'| cut -d':' -f1 | sort -n | uniq -c | sort -nr
the output is not much:
Code:
/var/www/vhosts/system # ss -tan state established | grep ":80\|:443" | awk '{print $4}'| cut -d':' -f1 | sort -n | uniq -c | sort -nr
      5 195.204.33.2
      3 92.221.64.26
      3 79.161.4.26
      3 212.33.158.58
      3 185.222.84.157
      3 [
      2 85.208.98.18
      2 45.140.0.100
      2 34.196.51.17
      2 213.0.108.66
      2 195.191.219.133
      2 195.191.219.132
      2 185.241.208.216
      2 127.0.0.1
      2 109.247.193.50
      1 97.74.211.129
      1 88.130.217.91
      1 84.165.144.222
      1 81.166.208.18
      1 81.166.126.41
      1 79.160.132.206
      1 77.16.217.174
      1 72.167.254.247
      1 69.162.124.231
      1 66.249.70.7
      1 62.92.155.205
      1 62.73.122.13
      1 52.21.236.0
      1 51.38.41.215
      1 51.222.253.14
      1 51.222.253.12
      1 51.195.216.60
      1 46.5.214.22
      1 45.135.241.228
      1 44.205.161.253
      1 37.157.255.193
      1 35.169.190.168
      1 3.139.50.99
      1 217.76.155.236
      1 213.157.22.140
      1 209.97.145.94
      1 208.109.71.255
      1 195.159.179.30
      1 194.5.175.226
      1 194.248.36.146
      1 192.42.116.178
      1 185.73.26.204
      1 18.216.127.212
      1 17.58.56.7
      1 165.232.180.139
      1 138.32.168.34
      1 137.184.98.241
      1 130.180.4.121
      1 103.108.45.105
Looks legit to me, Tried some lookup. The only strange is 3 [
 
Look at plesk backend Domains -> Logs and filter statur 400. If I had to guess, some is trying sqlinjections. Then you have to work on your Sec-rules and or htaccces and/or proxy-dns like Cloudflare ... They do it by large caputred Cnetworks, so it looks like a single IP from the first view. With that behavior the ship around fail2ban (one Ip is only a single try, after the standard ban period the ip try again) Had someting like that last october.
 
/var/www/vhosts/system # ss -tan state established | grep ":80\|:443" | awk '{print $4}'| cut -d':' -f1 | sort -n | uniq -c | sort -nr
Looking at current connections will probably not help. Instead, you'll need to check the access_ssl_log files of your website(s). A good start is to first check which users' PHP-FPM is active (like # ps aux | grep php-fpm). Normally you'll directly see where a lot of cpu load is created. Then check the website's access_ssl_log for frequent IP addresses other than your own, e.g. # cat access_ssl_log | awk '{print $1}' | sort -n | uniq -c | sort -n. Then either ban the culprit, e.g. # fail2ban-client set recidive banip <IP-address>. Or better: improve a suitable Fail2Ban jail definition to cover the case.
 
Back
Top