These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for bw.pl up to 100% cpu usage for 20 min on the new forum.
Hi,
Our bw.pl is taking up to 100% CPU usage for about 20 minutes each hour. This slows down the entire machine. I don't think this is normal.
Is this maybe a know issue? What can I do about it? I've already used nice to to make the impact less on the rest of the system.
Some information:
Virtualmin 3.56 (Pro) Upgrade from 2.609 Linux CentOS 5.1 AMD Dual-Core AMD Opteron(tm) Processor 2214 HE stepping 02
If more information is needed please let me know.
Thanks.
Any ideas?
It isn't a known issue. There have been some bw.pl performance bugs in the very distant past...but not in at least a year.
However, bandwidth reporting is a very resource intensive task--it's adding up every packet that enters and leaves your box (and every web page and email and whatever else could be hundreds or thousands of packets). That said, you've got a big box, so it shouldn't be taking more than a minute or so on each run.
Maybe the old bw.pl script is sticking around from the 2.609 version? I dunno...maybe check to be sure the script that is being called is actually the current version of bw.pl. I'm thinking maybe you have a tarball install rather than RPM, and there are old paths sticking around. Just guessing wildly, as I don't really have a good answer. But I do know that very old versions has some resource consumption bugs, and you are upgrading from a very old version, so it seems a possibility.
--
Check out the forum guidelines!
The script that's running is:
/usr/libexec/webmin/virtual-server/bw.pl
How can I see what version this is. It's not in file.
Any chance I could drop in on your box? (You can email login details to joe@virtualmin.com )
--
Check out the forum guidelines!
Anybody?
Mail send, thanks.
i have the same issue bw.pl goes way longer than a couple minutes and uses 100% cpu. i have the latest gpl version of virtualmin and the one that is being run is /usr/libexec/webmin/virtual-server/bw.pl which should be the right version.
did you find anything on his server that may help me ?
<div class='quote'>did you find anything on his server that may help me ? </div>
Things were working as designed on the original posters system...bw.pl <i>is demanding</i>. There is nothing we can do to make tracking every packet in and out of the system not require some resources--memory, CPU, and disk space.
Are you sure it's the same bw.pl process? Check to PID each time you check. In the cases I've looked into, the bw.pl process starts, runs for 20-30 seconds, and then exits correctly. Then, a few minutes later, a new one starts, runs for 20-30 seconds, exits, and so one. If you're not watching closely, it could seem like bw.pl is "always running" because it's running often and at a high CPU usage.
Be sure you're seeing what you think you're seeing.
bw.pl is set to run as "nice" as possible--so it won't use CPU that other processes want, but it will use as much as it can without stepping on other processes. This also means that if your box is working hard on other tasks (like mail delivery) bw.pl could run for longer than 20-30 seconds, as it is waiting for its share of the CPU to be available.
So, to sum up:
bw.pl is demanding, and will always be demanding. This is not a bug--it has a lot of work to do.
bw.pl probably isn't running forever, but it might run longer than it should, if other processes are demanding a lot of CPU. Make sure everything else on the system is running as efficiently as possible. Mail processing is the obvious first candidate for efficiency improvements. Switch to the daemonized versions of spam and AV processing, if you haven't already.
If, you are, in fact seeing bw.pl (the same PID) run for more than a couple of minutes, then there's probably a bug, and I'd want to look at it. But, we haven't had a bug report about bw.pl in at least a year that turned out to be an actual bug--it's pretty much always just that bw.pl is demanding, and people want it to be less demanding. We'd like that too, but Jamie's tuned it as much as is reasonable--we've tinkered with compiled log parsers and other stuff, but they turn out to be no faster (or even slower) than the Perl parser simply because Perls' regex engine and text processing tools are incredibly efficient by most measures (including when stacked up against tools in compiled languages).
But, we do want to know about it, if there is actually a misbehavior--I don't mean to sound discouraging. It just comes up a lot. ;-)
--
Check out the forum guidelines!