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 resource saturation. Most fix traffic I deal with is more bursty than steady. You may also get some hints on what the os is doing by monitoring /proc/interrupts and /proc/softirqs. Why are you running with HT enabled? Does it offer better performance characteristics in your case?
On Mon, 29 Jan 2018, 10:36 Ivan Valeriani, <[email protected]> wrote: > 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, SandyBridge. > > I would like to understand where these tasks are coming from and why they > can’t be processed. I do not have root access. > > I might have a few theories, but the question it’s rather on how I could > collect evidences. > > Many thanks > Ivan > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
