linux中进程上下文频繁切换导致loadaverage过高处理VIP免费

linux中进程上下文频繁切换导致loadaverage过高处理在linux中进程上下文频繁切换导致loadaverage过高问题我们要如何来解决呢，今天小编来为各位介绍一下此问题的解决办法。现网有两台虚拟机主机95%的cpu处于idle状态，内存使用率也不是特别高，而主机的loadaverage达到了40多。先在主机上通过top、free、ps、iostat等常用工具分析了下主机的CPU、内存、IO使用情况，发现三者都不高。通过vmstat1查看的结果如下：从vmstat的输出结果来看，io项的blockin和blockout并不频繁。而system项的每称的中断数（in)、每秒的上下文切换（cs）特别频繁。这就造成loadavaerage会特别高。大方向上的根因找到了，具体是哪个进程如何频繁的进行中断和上下文件的切换呢？这里使用pidstat-w1（每秒刷新输出上下文切换情况），输出见下图：从上图中可以看到有cswch(自愿的上下文切换)和nvcswch(非自愿的上下文切换)及对应的命令，出vsftpd占用的文件交换比较多。可以看到这里显示的cs值和总值还是有比较大的差距，由于主机上启动了不止一个vsftpd进程，而且pidstat通过1秒刷新的时候并不会显示所有，通过pidstat-w执行几次收集所有发现所有的vsftpd进程占用的cs值叠加和vmstat里的比较相近了。将结果通知业务人员后，和业务人员的猜测也一致，由于ftp使用的目录结构层次较深、文件数也比较多，业务在备份老的使用目录并重新创建单层目录后，观察一段后，发现loadaverage降下来了，稳定在1以下。当然这里只是处理方法的一种，现网中有些程序不好进行这样的修改的，又不让让进程在cpu之间频繁切换的，也有通过设置固定运行的CPU上进行调优的方法，如下两个进程运行在0－7号cpu上：[root@www~]#taskset-c-p6389pid6389'scurrentaffinitylist:0-7[root@www~]#taskset-c-p6580pid6580'scurrentaffinitylist:0-7可以通过taskset让其固定在0－1号cpu上运行：[root@www~]#taskset-c0,1-p6389这样做的原理是每当进程在切换到下一个cpucore上进会flush当前的cache数据，指定CPU时会减少这样的操作，增加进程的处理速度。这个对老的程序调优时比较有效。三、有关上下文切换1、上下文切换的理解什么是上下文件切换呢？引用老外的一句话：Acontextswitch(alsosometimesreferredtoasaprocessswitchorataskswitch)istheswitchingoftheCPU(centralprocessingunit)fromoneprocessorthreadtoanother.更详细的说明可以参看linfo站点或维基百科。contextswitch过高会导致CPU像个搬运工，频繁在寄存器和运行队列之间奔波，更多的时间花在了线程切换，而不是真正工作的线程上。直接的消耗包括CPU寄存器需要保存和加载，系统调度器的代码需要执行。间接消耗在于多核cache之间的共享数据。2、引起上下文切换的原因对于抢占式操作系统而言，大体有几种：当前任务的时间片用完之后，系统CPU正常调度下一个任务；当前任务碰到IO阻塞，调度线程将挂起此任务，继续下一个任务；多个任务抢占锁资源，当前任务没有抢到，被调度器挂起，继续下一个任务；用户代码挂起当前任务，让出CPU时间；硬件中断；什么样的操作会引起CS，这里有一篇博文感觉写的很不错，虽然其中的代码部分并不是理解。其中有如下几句话：linux中一个进程的时间片到期，或是有更高优先级的进程抢占时，是会发生CS的，但这些都是我们应用开发者不可控的－－－前面一部分描述的很到位，后面一部分在系统层面和kernel开发层面可以调用nice或renice进行设置优先级以保证某些程序优先在CPU中的占用时间，但也不能细化到CS层面。站在开发者的角度，我们的进程可以主动地向内核申请进行CS。操作方法为：休眠当前进程/线程；唤醒其他进程/线程。3、上下文切换测试工具1、LMbench是带宽（读取缓存文件、内存拷贝、读写内存、管道等）和反应时间（上下文切换、网路、进程创建等）的评测工具；2、micro-benchmarkcontextswitch可以测试不同的CPU在最少多少ns可以进行一次上下文件切换，再转化为秒，我们可以确认该处理器每可以进行的上下文件切换数，该工具的使用可以参看tsuna的blog。4、上下文切换的查看方法sar-w，这个只是能看出主机上总的上下文件切换的情况#sar-w1proc/s...