Huge CPU load in ALMA 8.10 / WHM 120.0.9
Hello All,
Suddenly a VPS with Alma 8.10 & WHM 120.0.9 (that was elevated from CENTOS 7.9 three months ago) has started acting weird: In a system with 8 CPUs it reaches load more than 35. We restart the PHP-FPM and the load drops for some 1-2 hours and then rises again.
The VPS has only 5 wordpress sites. Can anyone help on this?
Thanks!
-
Ah, so im not the only one.
Use almalinux 8.10 too,
cPanel Versionbut suddenly 5-6 hours ago the vps stopped suddenly and I need to start it manually. seems like a lot of mysql depreciation error, + WHM IO statistics also seeems so high and weird.0 -
and it keep randomly stopped sometimes, i need to manually start the vps back.
and also its happening starting the backup cpanel time, around 5-6 hours ago. And the backup also isnt completed because of the vps stopped itself.
0 -
I dont know why but it seems normal and better already now, I didnt do anything to fix it though. the IO Statistic also seems better lower than 100 Trans./Sec
0 -
Glad to getting better! Can you share more info? What VPS and what apps you host?
0 -
same OS, same cpanel version as your post. I host multiple websites inside there.
But I think its because of the IO statistic that going crazy before. which I dont know why, maybe backup not completed (because the vps auto shutdown) might cause it.
How about you, still not resolved ?
0 -
Still not resolved...Load Averages
24.64 22.40 23.36 while in the previous years it was always between 2-4 ... It seems like an Almalinux issue. Still investigating.
0 -
What virtualization is your VM on? My first guess would be either the host server node is swapping or your VM is swapping - check what processes are running and what your swap memory is doing.
0 -
Hello, the swap is not in use, the ram is used only by 20%... Just huge load (25 that sometimes goes to 40) ..... I really do not understand what is going on!
0 -
Shared hypervisor host? What virtualization is your VM on? If not your VM maybe another VM on the server is swapping.
0 -
I am not sure what you mean... I dont know if this helps "AlmaLinux v8.10.0 STANDARD kvm"
It is a VPS hosted by a major host in Germany.
0 -
You need to ask your host to investigate and control the VM causing the high loads for everyone on the server.
0 -
We did so. Furthermore we see (in logs) an ongoing DoS attack to the server.... so, it seems we found what causing it...
0 -
actually yesterday i saw a lot of connection from the same IP from china. didnt check since then.
0 -
Right now, it happens again. with very high IO statistics.
0 -
Check the hosted sites as well .... In our case the whole issue was started from an outdated wordpress with security holes......
0 -
it just happens sometimes, starting the day you post this.
when it happens, the IO statistic reading are so high. but will be better and better.
0 -
Another useful measure is to disable ssh server (stop daemon). So the malicious users cannot find the root login telnet port... please note that afterwards you can access the server only via WHM and not by terminal any more.
0 -
Anything new about this topic ? I faced same issue this happens randomly Load Average goes up and after 2-3 minute it coming down
0 -
This isn't unusual, especially during hourly or daily server crons. Thread demand and use will rise when your server is performing it's daily tasks, and the hourly tasks and all websites are also running their hourly cron jobs...
The best remedy for this is staggering crons, because most people will schedule all crons to run at the change of hour (HH:00), which obviously will cause temporary usage spikes while all the jobs compete for the same resources...
I try to at least run all the server-level crons off-hour, because, let's face it, clients will do whatever they do, and mostly that's run all crons at the very same time.
Another way to protect resources if the issues exacerbate or persist is offload some servers (such as Nameservers, Mail, Database) to run on their own separate instances. This method would likely yield best results and, as such, provide a more long-term solution to the issue you reported.
Unfortunately, it would require the greatest initial investment of work/time to implement, but again it should offer real results when compared to other, easier fixes.0 -
The source of the issue was php-fpm. we made adjustments to the settings and manage to solve the issue. It was especialy related to php 8.1, version that we finally removed form the server. It was although not limited to this ver. of PHP. but in this it was the biggest problem.
Regards to all fellow administrators!
0 -
If u see the pattern, we can say that we keep going to this thread around weekend.
Seems that the attack to web server is frequently at this time which I could say mostly contributed on this.
0 -
I am having the same issues. What was the fix?
0 -
Check your logs. In my case most of the stress was caused by unupdated PHP packets, as well as by poor MariaDB performance settings. Check log files in /var/log/ for possible issues .... As for the login attacks, then you can set appropriately your firewalls, your modsec config as well as you can use some login banning tool such as the fail2ban.
0
Please sign in to leave a comment.
Comments
23 comments