In addition to what others have said: - eBPF script: https://www.brendangregg.com/blog/2016-10-08/linux-bcc-runqlat.html https://www.brendangregg.com/blog/2016

In addition to what others have said: - eBPF script: https://www.brendangregg.com/blog/2016-10-08/linux-bcc-runqlat.html https://www.brendangregg.com/blog/2016-10-08/linux-bcc-runql... - perf sched: https://www.brendangregg.com/blog/2017-03-16/perf-sched.html https://www.brendangregg.com/blog/2017-03-16/perf-sched.html - schedlat: https://tanelpoder.com/posts/schedlat-low-tech-script-for-measuring-cpu-scheduling-latency-on-linux/ https://tanelpoder.com/posts/schedlat-low-tech-script-for-me... The last one (written by me) is using /proc/PID/schedstat pseudofile for monitoring % time spent in the CPU runqueue of a single process (not systemwide). I don't always have (root) access for running perf or eBPF scripts (or the old Linux/kernel version don't allow that). But I can still measure how much time a process on a request's critical path (like a RDBMS transaction log writer on commit) spent waiting to get back onto CPU before doing any work. Like others have already said, the OS CPU queuing/scheduling latency is just one component contributing to the total responsiveness/reaction latency of your app.