Performance metrics

[unixronin]

On babylon5, I run procmeter3 for general system activity monitoring.  But in my new-to-me laptop, whitestar, the version I have has a compatibility issue with something that's causing it to crash as soon as any NFS volume is mounted by any method.  So until I resolve the problem, I'm temporarily running gkrellm on whitestar.

It seemed to me like whitestar's CPU seemed ... kinda busy for an idle machine.  So I looked at the CPU usage stats.  Then I looked at cumulative CPU usage against uptime. Procmeter3 on babylon5 had consumed 34 seconds of CPU time in 11 days and 2 hours. Gkrellm/d on whitestar had consumed 56 minutes of CPU time in not quite 33 hours. Per unit time, gkrellm and gkrellmd together on whitestar are consuming almost a thousand times as many CPU cycles as procmeter3 on babylon5, on the same processor architecture running at the same speed, to display the same information.

Any time you have a tool that does exactly the same job as someone else's tool, but takes a thousand times as much CPU time to do it, it should be a sign that you wrote some really crappy code.

Update, 0110:  Turns out the procmeter3 issue I was running into was an ACPI bug that is fixed in v3.5b. Problem solved, procmeter3 all happily configured on whitestar and working.

Comments

[unixronin.livejournal.com]

[checks] just volume and cpufreq. I'd also installed the hddtemp plugin initially, but discovered that (a) it was crashing gkrellm and (b) I could get that readout internally without using the plugin anyway.

Anyway, I'm happier with procmeter3. Not only does it use far less CPU, I can embed it seamlessly into my desktop, which I can only partially do with gkrellm.

[robbat2.livejournal.com]

just out of interest, could you poke and see if it was hddtemp or volume that was causing the excess CPU?

DOH!

[unixronin.livejournal.com]

This morning, less tired, I realized my math was off because the same gkrellm and procmeter have not been continuously running. They get restarted fresh each morning when I log in.

Still, at 56 minutes vs. 34 seconds, gkrellm is still using over a hundred times as much CPU as procmeter3.

I uninstalled gkrellm once I got procmeter3 working, so I can't readily poke at it right now without reinstalling it. I wasn't actually using the hddtemp module; I tried to, but then discovered that I could get the hdd temp through gkrellm builtins anyway, which was just as well given that the hddtemp module wasn't working for me (it crashed gkrellm any time I tried to start it).

I'm thinking procmeter3 might be a good candidate for me to use as my first "how do I create an ebuild" example. It's a good tool. And probably Xcoral after that. And by then I might with luck be ready to update the Bacula ebuild to v3.0.2.