现网有两台虚拟机主机95%的cpu处于idle状态,内存使用率也不是特别高,而主机的load average达到了40多。
先在主机上通过top、free、ps、iostat 等常用工具分析了下主机的CPU、内存、IO使用情况,发现三者都不高。通过vmstat 1 查看的结果如下:
从vmstat的输出结果来看,io项的block in 和block out 并不频繁。而system项的每称的中断数(in)、每秒的上下文切换(cs)特别频繁。这就造成load avaerage会特别高。大方向上的根因找到了,具体是哪个进程如何频繁的进行中断和上下文件的切换呢?
这里使用pidstat -w 1 (每秒刷新输出上下文切换情况),输出见下图:
从上图中可以看到有cswch(自愿的上下文切换)和nvcswch(非自愿的上下文切换)及对应的命令, 出vsftpd占用的文件交换比较多。可以看到这里显示的cs 值和总值还是有比较大的差距,由于主机上启动了不止一个vsftpd进程,而且pidstat 通过1秒刷新的时候并不会显示所有,通过pidstat -w执行几次收集所有发现所有的vsftpd进程占用的cs值叠加和vmstat里的比较相近了。
将结果通知业务人员后,和业务人员的猜测也一致,由于ftp使用的目录结构层次较深、文件数也比较多,业务在备份老的使用目录并重新创建单层目录后,观察一段后,发现load average降下来了,稳定在1以下。
当然这里只是处理方法的一种,现网中有些程序不好进行这样的修改的,又不让让进程在cpu之间频繁切换的,也有通过设置固定运行的CPU上进行调优的方法,如下两个进程运行在0-7号cpu上:
可以通过taskset让其固定在0-1号cpu上运行:
这样做的原理是每当进程在切换到下一个cpu core上进会flush当前的cache数据,指定CPU时会减少这样的操作,增加进程的处理速度。这个对老的程序调优时比较有效。
1、上下文切换的理解
什么是上下文件切换呢?引用老外的一句话:A context switch (also sometimes referred to as a process switch or a task switch) is the switching of the CPU (central processing unit) from one process or thread to another。
context switch过高会导致CPU像个搬运工,频繁在寄存器和运行队列之间奔波 ,更多的时间花在了线程切换,而不是真正工作的线程上。直接的消耗包括CPU寄存器需要保存和加载,系统调度器的代码需要执行。间接消耗在于多核cache之间的共享数据。
2、引起上下文切换的原因
对于抢占式操作系统而言, 大体有几种:
什么样的操作会引起CS,这里有一篇博文感觉写的很不错,虽然其中的代码部分并不是理解 。其中有如下几句话:
linux中一个进程的时间片到期,或是有更高优先级的进程抢占时,是会发生CS的,但这些都是我们应用开发者不可控的 ---前面一部分描述的很到位,后面一部分在系统层面和kernel 开发层面可以调用nice 或 renice进行设置优先级以保证某些程序优先在CPU中的占用时间,但也不能细化到CS层面。
站在开发者的角度,我们的进程可以主动地向内核申请进行CS 。操作方法为:休眠当前进程/线程;唤醒其他进程/线程 。
3、上下文切换测试工具
1、LMbench 是带宽(读取缓存文件、内存拷贝、读写内存、管道等)和反应时间(上下文切换、网路、进程创建等)的评测工具;
2、micro-benchmark contextswitch 可以测试不同的CPU在最少多少ns可以进行一次上下文件切换,再转化为秒,我们可以确认该处理器每可以进行的上下文件切换数 ,该工具的使用可以参看tsuna的blog。
sar -w ,这个只是能看出主机上总的上下文件切换的情况
同样,vmstat也可以查看总的上下文切换情况,不过vmstart输出的结果更多,便比通过对比发现问题:
查看每个进程或线程的上下文件使用情况,可以使用pidstat命令或者通过查看proc 。
cswch/s: 每秒任务主动(自愿的)切换上下文的次数,当某一任务处于阻塞等待时,将主动让出自己的CPU资源。
nvcswch/s: 每秒任务被动(不自愿的)切换上下文的次数,CPU分配给某一任务的时间片已经用完,因此将强迫该进程让出CPU的执行权。
上下文切换部分零零碎碎先到这里吧,只是想说明上下文切换还是比较重要的一个指标的。nagios check_mk默认有对上下文的监控,其使用的方法是通过两/proc/stat文件里取到ctxt行,并取两个时间段之间的差值来确认。