Hi everybody.

After I installed the latest kernel image on Debian 10 I got high CPU Usage Notification from my Observium Monitoring System. The check goes over snmp. I checked the System itself, but there was no CPU high Usage, everything seems to be OK. I checked a lot of thing, but can't find any issue or problem.

After I goes back to Kernel Version 5.11.0-21.2-liquorix-amd64, Observium get right Values and CPU usage shows ok.

can you check if something happens with snmp or what else in kernel params? did something went wrong? does anybody have se same issue?

BR.

Torsten

CPU Load Graph: [new user link]
Back to top

Rather than post about a bit of software nobody can be expected to have or use, why not skip a step and confirm the issue exists with htop?

run it, and see what your cpu usage is, then also see what's eating up the cpu cycles using the sort option. If you can't confirm the issue exists using htop, or at least top, then you may be looking at an issue with your software, but there's no way to know that without real data.
Back to top

I think you're using a KVM based virtualization system. For some reason in 5.12, MuQSS reports idle CPU as IO-wait in KVM. It's benign but trips monitoring systems. Your monitoring system is treating IO-wait as user space CPU (which isn't correct), so that's why it's showing a high CPU load when there isn't any.
Back to top

Yes. You're right. I using ProxMox as virtualisation system and all machines are vms. this is why I said it must be something in the kernel, because 5.11. works fine and 5.12 shows cpu high usage only in observium, but system hasn't a cpu high usage.

if I understand it right, this could be a ticket for observium support itself? do they show the wrong value?
Back to top

Possibly, it's most likely that Observium would prefer not changing the way they calculate CPU usage, but it technically is correct to use user/kernel CPU and put IO-wait in its own category. The definition of IO-wait is that the CPU is waiting on IO from something else, so it's technically not doing anything if that percent is high.
Back to top

This would warrant a bug report to observium, upstream that is, from what damentz says. This was my initial suspicion, though I didn't know the 'why' of it. For smaller software projects that are not widely used, never underestimate the value of the time you spend filing the bug report, it will often result in a quick fix, and if it instead results in excuses or zero response, that likewise lets you know that maybe you should not be relying on that particular bit of software. Either way it's time well spent since you learn important things either way, and if they are responsive, the bug will get corrected and your software will work the way you expect. Not taking action results in you hoping someone else does it for you, which is not a good strategy to use on niche software.
Back to top

This should be resolved in Liquorix for 5.14. I switched the CPU scheduler from MuQSS to PDS due to Con discontinuing MuQSS and no good port existing in the wild. PDS does a much better job syncing with mainline so things like time accounting match upstream far more closely than MuQSS ever did.

Let me know if you still have issues.
Back to top

Marking as resolved, a related github issue confirmed this is no longer an issue: github.com/damentz/liquorix-package/issues/59
Back to top