首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

[linux][bcc]使用runqslower发现调度延迟问题

前言 在高性能网络模型下,使用polling模式,依然遇到了长尾20ms+的情况,远高于平均的1ms左右。怀疑是调度的延迟导致的。那么如何量化是不是内核的调度导致的呢?以及如何发现是什么原因导致的呢? 分析 调度延迟 在前文《[Linux][kernel]sched delay和steal time的原理分析以及atop的监控改进》中分析过Linux中如何计算一个task的run delay:即一个task希望运行,但是得不到运行的时间统计,即run delay,也就是调度延迟。 那么问题来了,如果通过atop监控到某一个进程的run delay是2%,能说明那20ms的长尾延迟是因为调度延迟导致的吗?答案是不能。我们看下面的两种情况: 1,例如说,Run 19ms, Delay 1ms,Run 19ms, Delay 1ms,Run 19ms, Delay 1ms。在这个模型下,统计出来的run delay是2%。 2,另外一种模型下,例如 Run 980ms, Delay 20ms, Run 980ms, Delay 20ms,这个模型下,就会遇到20ms+的长尾延迟。 所以atop可以统计出来宏观的run delay延迟占比,但是不能统计出来具体的调度延迟极端情况。 runqslower工具 在bcc中提供了runqslower工具,可以通过参数控制,打印出来哪些进程的调度延迟超过了特定的阈值,例如希望知道哪些进程的run delay超过10ms,可以使用这样的命令:

04
领券