| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Debian 12 |
| Webmin version | 2.641 |
| Virtualmin version | 8.1.0 GPL |
| Webserver version | Apache 2 |
| Related packages | PHP 7.4, and 8.4 |
I have some long periods of very high CPU usage.
“[/usr/share/webmin] defunct” shows more than 50% constantly.
What could be causing this?
Try using top -i in an ssh session (or terminal session) to see what is using CPU.
Could you share with us a bit more about your environment?
The above plus anything else you feel may be relevant or helpful like tasks that may be scheduled during the spikes (backups, cron jobs).
This information will help us get a better picture into what may be the root cause.
I am using AWS with t3.medium.
Have updated now to 2.641 and 2.540
About 30 websites
[/usr/share/webmin] defunct is no longer visible.
never had that directory (that I can remember) but I do have /usr/share/webmin was that a typo or were you looking for exactly [/usr/share/webm] ?
Thats correct. Webmin
Most sites are Wordpress.
They often takes 100% CPU for php-fpm
If that’s the case I would start again as that is a catastrophic failure (not having the webmin modules) and I am surprised that webmin works at all without the files that are contained there in. So perhaps reprovision your instance and restore from backups
The Webmin module is ok.
It´s just the message that disappired
I dont understand, one minite your saying the webmin directory has disappeared (defunct) then you say a message has disappeared now I well confused at what your getting at
And hasn’t bothered to try top -i
Don’t forget webmin is the actual programme, everything that is managed by webmin is a module, for example virtualmin
I´m sorry. I did not know that.
And I tried top -i. Very good. Thanks.
It was the very first reply in this thread.
I hope it helps. 
Nobody said anything about a directory.
[defunct] means a process died/exited. The process list is not showing directories, it is showing process path and name. In this case, the path and name was truncated, so we don’t actually know what file it was that spawned the defunct process (there are many executables in /usr/share/webmin).
Thanks for providing the information requested.
So, just to clarify based on what I’ve read about the AWS tier you are on:
2 vCPUs
4GB RAM
Generally I’d say this should be sufficient for your 30 websites, though if you are seeing the CPU peak often, it’s likely due to either a combination of background (cron) tasks running at certain times, and/or plugins within the WP installs that may either be unoptimized, a bit buggy, or just the sheer amount of plugins being run plus website visits hitting the VM. The traffic factor is likely more bots then humans but either way this can place a lot of stress on the sites and therefore VM.
Exhausting the CPU and/or Memory can lead to things crashing within the VM, typically related to an OOM triggering processes and services to be shutdown or similar.
As you are using Debian, journalctl is your best friend for identifying errors and other factors that could be causing stress and crashing things like Webmin within your system.
I’m not sure, as I’ve not really used AWS compute services in a while, but do they have historic “charts” that might reveal when “spikes” are occurring, or have you observed these spikes in real-time?
It’d be interesting to see when they occur, and what might be running within the VM during that period. This would help determine whether you are dealing with “normal” overload like tasks that are competing for system resources, or spikes related to a potential bot attack…
Another thing to check is the “logs” for the sites themselves. In particular you want to be reviewing the top “biggest” (in terms of file size) “error logs” as they may reveal less obvious errors within your WP sites like misbehaving code that is not being seen, but handled by PHP but also creating spikes in resource usage as a result of the real-time fixing nature PHP often employs. The less work PHP needs to do to “fix” a running script the more resources you’ll get back for more or equally important tasks.
Oh, and another important distinction is, are you using this to ALSO host “email”? Email can introduce another level of resource usage in itself.
Have you thought in terms of bots?
Over the past several months I noticed a huge increase in CPU usage over many servers. Viewing logs I realized there seemed to be increasing error and access activity by bots. I implemented a WordPress filter, a 404 scanner filter, and an xmlrpc filter in Fail2Ban on all of the machines. This alone reduced my memory usage and most significantly my CPU usage dropped 20-30% in Virtualmin on Debian 12/13 systems. I use a checklist I made up that’s HERE for whoever wants to try it out. It also helped in a SmarterMail system on Debian 13. Fail2Ban also freed the systems up from the associated storage accesses caused by writing access and error logs from bad actors as well once they were banned.
Thansk for the notes, I will go over them.
On a related notes, my other non-virtualmin server was getting a lot of it’s accounts, running WordPress, resources maxed out and I could not work out why as they all has Total Cache running.
It turns out that bots/crawlers are using Cache Busting queries. So by appending a query onto the end of the URL call a new page is generated from the database every time which can be very resource intensive, especially if you are using Divi.
I have not come up with a solution yet, nor have I put too much time in to it as the current server resource limits.
These are some example URLs with the cache busting queries:
example.co.uk/?mdrv=www.example.co.uk
example.co.uk/services/?mdrv=www.example.co.uk
example.co.uk/services/social-media-management/?mdrv=www.example.co.uk
example.co.uk/privacy-and-cookies-policy/?mdrv=www.example.co.uk
Additional
I use WordFence WAF on all of my websites. You can disable XMLRPC calls of completely and lot of other stuff including rate limiting.
I was experiencing very high cpu/RAM usage spikes at certain times on a droplet with 2GB of RAM. In my case, I first created a RAM swap because the VPS didn’t have it by default, and then I disabled Virtualmin’s periodic monitoring for updates (it all seemed that this activity was causing the spikes on a VPS with moderate RAM). The problem was completely resolved, and now the VM notifies me of available updates when I log in manually. I’m not sure which of the two changes was the solution, but it worked.