Linux CPU上下文切换排查

1. 小声哔哔

    服务器CPU使用率飙高的原因有很多,CPU的上下文切换就是其中一种,Linux上下文切换请参照博文Linux 上下文切换,但是没有实际的场景验证终究是有纸上谈兵之嫌,所以本博文我们使用sysbench工具来尝试模拟多线程切换以达成增加CPU上下文切换的效果。

2. 正餐开始

  • 机器配置:2U2G
  • 机器内核:CentOS
  • 测试工具:sysbench(若机器无此命令可执行yum install sysbench -y安装)
  • 检测工具:vmstat,pidstat(对此命令不熟悉的同学可以参照博客:Linux进程系统使用监控pidstat命令

    本次模拟我们总计需要3个会话窗口,第一个会话窗口执行sysbench进行压测模拟,第二个窗口执行命令vmstat 2每两秒查看一次系统整体情况,第三个窗口执行pidstat -u -w 2每两秒输出一次本机进程的CPU使用情况和上下文切换时长。

    我的机器是2U2G单内核的,使用命令sysbench --threads=20 --max-time=600 threads run模拟20个线程持续10分钟抢占CPU。

    首先查看执行vmstat 的会话窗

可以发现执行sysbench后以下几个参数发生激增:

  • r列:就绪队列长度增长到9,10左右,远超CPU核数,必然有大量的CPU竞争。
  • in列:中断次数增长到2000,也是值得关注的参数
  • cs列:上下文切换增长到可怕的120万
  • us列:CPU用户态的使用率增长到40%左右
  • sy列:CPU系统态的使用率增长到60%左右,注意,已我的运维经验而言,CPU的系统态占比很高时往往意味着我们必须要排查到底是什么原因导致CPU占用较高。

然后我们关注pidstat -u -w 2的会话窗口

    明显可以看到sysbench的进程有些异常,但是有个很奇怪的点是cswch/s:每秒完成的进程的自愿上下文切换总数并不高,nvcswch/s:每秒完成的任务的非自愿上下文切换总数也不高。此时我们可以特别关注sysbench的进程,并使用参数-t关注其子进程,看是否是他干的坏事。

    使用命令pidstat -w -t -p [异常进程PID] 2

     这下内鬼抓到了,虽然 sysbench 进程(也就是主线程)的上下文切换次数看起来并不多,但它的子线程的上下文切换次数却有很多。

    此时你或许有个疑问,观察vmstat指标时中断次数也很多,但是不知道是哪种类型的中断,首先我们明确中断是发生在内核态的,我们可以到/proc/interrupts去读取中断的使用情况。

    执行命令:watch -d 'cat /proc/interrupts |tail -19'(-d高亮显示发生变化的数据)

     变化速度最快的是重调度中断(RES),和时钟中断(LOC):

    RES表示重调度中断,用于唤醒空闲状态的 CPU 来调度新的任务运行。这是多处理器系统(SMP)中,调度器用来分散任务到不同 CPU 的机制,通常也被称为处理器间中断(Inter-Processor Interrupts,IPI)。

    LOC时钟中断首先需要知道时钟的概念,时钟是整个操作系统的脉搏,它为进程的时间片调度,定时事件提供了依据。还记得我上文说的CPU调度任务是通过时间片轮转吗,这个也是时钟的应用。

    综上可以看出重调度中断和时钟中断都是由于多线程抢占CPU引发的,CPU被频繁唤醒导致RES中断升高,时间片切换导致LOC中断升高。

3. 小结

    由于能力有限,本博文仅仅是使用Linux提供的监控工具查看了上下文切换的指标变化,没有涉及底层代码的走读,希望以后可以更深一步,有任何的建议请留言交流。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值