Thanks to both of you. I’ll digest your suggestions and come back with some
founding.
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy
When you say "run-queue" below, I assume you are referring to the "r"
column in vmstat output, right? That's not the run queue depth...
While the vmstat man pages (e.g. https://linux.die.net/man/8/vmstat)
*misleadingly* describe the "r" column with "r: The number of processes
waiting for run ti
I'd just run stap or ftrace to capture sched_switch events to see what's
causing the scheduling pressure.
Are there any anomalies in voluntary and involuntary context switching
during the run queue length spikes?
Also, depending on your load running several spinning fix engine threads
may cause res
Hello,
Running vmstat on a production box, I am seeing run-queue suspiciously high and
occasionally spiking up to double digit. Say:
Avg = 7.1
Std = 5.33
Min = 4
Max = 31
Top(1) shows 80% idle cpu.
This box runs 6 fix engines, 1 spinning thread each. It’s running 16x2
hyperthreaded cores, San
