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

[robbat2.livejournal.com]

That use on your gkrellm seems weirdly high.
56m / 33h = 2.8%
34s / 11d2h = 0.0036%

My gkrellm (with update freq 10Hz):
3h48m / (4 cores * 29d19h) = 0.13%

Plugins in use here:
- calendar
- clock
- cpu usage graph
- 6 hw temp sensors
- 3 fan speed sensors
- network usage, internal interface
- network usage, external interface
- memory stats
- swap stats
- local METAR feed
- keyboard led indicators

I tried conky and some of the others for a while, but they had usage in the 5-10% range, which was extremely unacceptable.

[unixronin.livejournal.com]

That use on your gkrellm seems weirdly high.

Yeah, I thought so too. I wondered what was causing so much CPU activity on an "idle" machine, so I opened up top and was surprised to find it was gkrellm.

Anyway, I've solved the procmeter3 problem; it turned out to be an ACPI bug that's fixed in procmeter3-3.5b. So now I have procmeter3 working fine on whitestar, gkrellm is goneski, and my idle CPU usage is back to essentially zero.

Now if I could just fix my wonky temperature sensor ...


(Right now, the cpu is throttled down to minimum, the fan is barely even running, fan exhaust is barely even warm, procmeter3 says thermal zone 1 OK, acpitool -e says thermal zone 1 OK, acpi -t says thermal zone is critical, and both acpi -t and acpitool -e say CPU temperature is 177°C. Which I don't believe for a single second. This temperature sensor has a line spectrum — the temperatures it has ever displayed while in my ownership form a discrete set: 29, 30, 59, 96, 97, 98, 135, 177. At the time that 29°C was reported, that was actually below room temperature, which would be a hell of a neat thermodynamic trick if it were true.)

[robbat2.livejournal.com]

Years ago I mucked with a Peltier cooler on top of an K6-3, and that's the only time I've had a legitimate readout of below room temp.

What plugins did you have in your gkrellm? I should add that all of my sensors were the kernel sensor framework, not ACPI.

[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.