Ukri Niemimuukko

The cpu (-freq) collector(s) parallelize a lot, which can cause a sudden burst of threads accessing related kernel functionality pretty much at the same time. Could you try running node_exporter...

A long time ago I recall suggesting not to do frequency querying for hyperthreaded cores. The frequency for those is always the same as for the physical core, so one...

I can verify that this can be an issue also for certain high core count Xeons running short-ish scrape intervals, and the workaround is disabling of cpufreq collector. I haven't...

> Can y'all confirm this happens with both the cpu and the cpufreq collector? For us disabling cpufreq-collector was sufficient to bring the load down and the nagging from the...

> @uniemimu Can you try setting GOMAXPROCS=1, enable the cpufreq collector and see if you still see the issue? It is better, and doesn't get out of control anymore in...

> Any chance we could get access to one of these systems to do some tracing? Unfortunately, I have no such hardware to test with. From my side I can't...

Meanwhile I took a look at kernel.map which I happened to find, and the thing node_exporter is reaching for in the kernel points to osq_lock. Which to me makes perfect...

[pprof_tree.txt](https://github.com/prometheus/node_exporter/files/5964933/pprof_tree.txt)

In fact other plugins do support fractional resources as well, albeit via forks. I wouldn't go as far as touting that feature, nor the monitoring resource which gives access to...

@eero-t byako wasn't perhaps descriptive enough above. With `-o yaml` in the end you can see the content. Try ` kubectl apply --dry-run=client -k https://github.com/intel/intel-device-plugins-for-kubernetes/deployments/gpu_plugin?ref=v0.24.0 -o yaml` In any case...