首页 & Linux/unix/mac进程上下文频繁切换导致load average过高 一、问题现象 现网有两台虚拟机主机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上：[root@www ~]# taskset -c -p 6389
pid 6389's current affinity list: 0-7
[root@www ~]# taskset -c -p 6580
pid 6580's current affinity list: 0-7 可以通过taskset让其固定在0－1号cpu上运行：[root@www ~]# taskset -c 0,1 -p 6389 这样做的原理是每当进程在切换到下一个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.更详细的说明可以参看linfo站点 或 维基百科 。 context switch过高会导致CPU像个搬运工，频繁在寄存器和运行队列之间奔波 ，更多的时间花在了线程切换，而不是真正工作的线程上。直接的消耗包括CPU寄存器需要保存和加载，系统调度器的代码需要执行。间接消耗在于多核cache之间的共享数据。 2、引起上下文切换的原因 对于抢占式操作系统而言， 大体有几种： 当前任务的时间片用完之后，系统CPU正常调度下一个任务； 当前任务碰到IO阻塞，调度线程将挂起此任务，继续下一个任务； 多个任务抢占锁资源，当前任务没有抢到，被调度器挂起，继续下一个任务； 用户代码挂起当前任务，让出CPU时间； 硬件中断； 什么样的操作会引起CS，这里有一篇博文感觉写的很不错，虽然其中的代码部分并不是理解 。其中有如下几句话： linux中一个进程的时间片到期，或是有更高优先级的进程抢占时，是会发生CS的，但这些都是我们应用开发者不可控的 －－－前面一部分描述的很到位，后面一部分在系统层面和kernel 开发层面可以调用nice 或 renice进行设置优先级以保证某些程序优先在CPU中的占用时间，但也不能细化到CS层面。 站在开发者的角度，我们的进程可以主动地向内核申请进行CS 。操作方法为：休眠当前进程/线程；唤醒其他进程/线程 。 3、上下文切换测试工具 1、LMbench 是带宽（读取缓存文件、内存拷贝、读写内存、管道等）和反应时间（上下文切换、网路、进程创建等）的评测工具； 2、micro-benchmark contextswitch 可以测试不同的CPU在最少多少ns可以进行一次上下文件切换，再转化为秒，我们可以确认该处理器每可以进行的上下文件切换数 ，该工具的使用可以参看tsuna的blog。 4、上下文切换的查看方法 sar -w ，这个只是能看出主机上总的上下文件切换的情况# sar -w 1
Total number of tasks created per second.
Total number of context switches per second. 同样，vmstat也可以查看总的上下文切换情况，不过vmstart输出的结果更多，便比通过对比发现问题：# vmstat 3
procs -----------memory----------
---swap-- -----io----
-system-- ----cpu----
cs us sy id wa
0 查看每个进程或线程的上下文件使用情况，可以使用pidstat命令或者通过查看proc 。# pidstat -w
每个进程的context switching情况
# pidstat -wt
细分到每个threads
查看proc下的文件方法如下：
# grep ctxt /proc/$pid/status
voluntary_ctxt_switches:
#自愿的上下文切换
nonvoluntary_ctxt_switches:
#非自愿的上下文切换 cswch/s: 每秒任务主动(自愿的)切换上下文的次数，当某一任务处于阻塞等待时，将主动让出自己的CPU资源。 nvcswch/s: 每秒任务被动(不自愿的)切换上下文的次数，CPU分配给某一任务的时间片已经用完，因此将强迫该进程让出CPU的执行权。 上下文切换部分零零碎碎先到这里吧，只是想说明上下文切换还是比较重要的一个指标的。nagios check_mk默认有对上下文的监控，其使用的方法是通过两/proc/stat文件里取到ctxt行，并取两个时间段之间的差值来确认。# cat /proc/stat|grep ctxt
本站的发展离不开您的资助，金额随意,欢迎来赏！
分类: Linux/unix/mac linux高级篇, 故障案例您可能也喜欢linux comet模型下的连接数统计 linux内存管理 linux内存分配与回收 ipcs与Linux共享内存 Linux超强的系统挖掘工具sysdig 捐助本站
如您感觉本博客有用，可扫码向本博客捐赠近期文章 使用ssldump解密https数据包 RH5885映射管理口不能用 普通用户无法修改密码问题处理 skydns编译安装 Confd+etcd实现高可用自动发现文章归档 文章归档 选择月份 2017年七月 &(2) 2017年六月 &(1) 2017年五月 &(3) 2017年三月 &(3) 2017年二月 &(2) 2017年一月 &(4) 2016年十二月 &(4) 2016年十一月 &(6) 2016年十月 &(5) 2016年九月 &(5) 2016年八月 &(9) 2016年七月 &(4) 2016年六月 &(10) 2016年五月 &(18) 2016年四月 &(5) 2016年三月 &(4) 2016年二月 &(5) 2016年一月 &(8) 2015年十二月 &(8) 2015年十一月 &(9) 2015年十月 &(17) 2015年九月 &(10) 2015年八月 &(24) 2015年七月 &(11) 2015年六月 &(15) 2015年五月 &(23) 2015年四月 &(14) 2015年三月 &(22) 2015年二月 &(15) 2015年一月 &(24) 2014年十二月 &(13) 2014年十一月 &(16) 2014年十月 &(19) 2014年九月 &(19) 2014年八月 &(18) 2014年七月 &(20) 2014年六月 &(21) 2014年五月 &(24) 2014年四月 &(17) 2014年三月 &(29) 2014年二月 &(22) 2014年一月 &(22) 2013年十二月 &(24) 2013年十一月 &(20) 2013年十月 &(18) 2013年九月 &(16) 2013年八月 &(16) 2013年七月 &(20) 2013年六月 &(21) 2013年五月 &(19) 2013年四月 &(18) 2013年三月 &(24) 2013年二月 &(21) 2013年一月 &(18) 2012年十二月 &(24) 2012年十一月 &(18) 2012年十月 &(17) 2012年九月 &(17) 2012年八月 &(18) 2012年七月 &(26) 2012年六月 &(36) 2012年五月 &(36) 2012年四月 &(28) 2012年三月 &(46) 2012年二月 &(23) 2012年一月 &(15) 2011年十二月 &(27) 2011年十一月 &(59) 2011年十月 &(19) 2011年九月 &(16) 2011年八月 &(46)linux系统平均负载（load&&average）
关于平均负载，网上有篇文章有更好的解释:
(转自/blog/linux-load-average-three-numbers.html)
越来越多人开始接触Linux操作系统，从VPS到无线路由的刷机系统(如OpenWRT、Tomato)，同时也必不可少地会在各式各样的探针和系统监测界面上看到"系统平均负载"或者"Load
Average"这样的字眼，但是它并不像我们习惯中Windows、Mac操作系统提供百分比显示CPU、内存占用率，而是以几个用空格隔开的浮点数来表示系统平均负载，那么它们到底是什么意思呢？又如何衡量系统负载及系统的稳定性呢？
系统平均负载-基本解释
在Linux shell下，有很多命令可以看到Load Average，例如：
:~# uptime
12:49:10 up 182 days, 16:54, 2 users, load average: 0.08, 0.04,
12:49:18 up 182 days, 16:54, 2 users, load average: 0.11, 0.07,
top - 12:50:28 up 182 days, 16:55, 2 users, load average: 0.02,
0.05, 0.00
先大致给一下这3个数字的含义：分别表示系统在过去1分钟、5分钟、15分钟内运行进程队列中的平均进程数量。
运行队列嘛，没有等待IO，没有WAIT，没有KILL的进程通通都进这个队列。
另外还有一个最直接的显示系统平均负载的命令
:~# cat /proc/loadavg
0.10 0.06 0.01 1/72 29632
除了前3个数字表示平均进程数量外，后面的1个分数，分母表示系统进程总数，分子表示正在运行的进程数；最后一个数字表示最近运行的进程ID.
系统平均负载-进阶解释
只是上面那一句话的解释，基本等于没解释。写这篇文章的缘由就是因为看到了一篇老外写的关于Load
Average的文章，觉得解释的很好，所以才打算摘取一部分用自己的话翻译一下。
@scoutapp Thanks for your
article&, I just
translate and share it to Chinese audiences.
为了更好地理解系统负载，我们用交通流量来做类比。
1、单核CPU - 单车道 - 数字在0.00-1.00之间正常
路况管理员会告知司机，如果前面比较拥堵，那司机就要等待，如果前面一路畅通，那么司机就可以驾车直接开过。
具体来说：
0.00-1.00 之间的数字表示此时路况非常良好，没有拥堵，车辆可以毫无阻碍地通过。
1.00 表示道路还算正常，但有可能会恶化并造成拥堵。此时系统已经没有多余的资源了，管理员需要进行优化。
1.00-*** 表示路况不太好了，如果到达2.00表示有桥上车辆一倍数目的车辆正在等待。这种情况你必须进行检查了。
2、多核CPU - 多车道 - 数字/CPU核数在0.00-1.00之间正常
多核CPU的话，满负荷状态的数字为 "1.00 * CPU核数"，即双核CPU为2.00，四核CPU为4.00。
3、安全的系统平均负载
作者认为单核负载在0.7以下是安全的，超过0.7就需要进行优化了。
4、应该看哪一个数字，1分钟，5分钟还是15分钟？
作者认为看5分钟和15分钟的比较好，即后面2个数字。
5、怎样知道我的CPU是几核呢？
使用以下命令可以直接获得CPU核心数目
grep 'model name' /proc/cpuinfo | wc -l
取得CPU核心数目N，观察后面2个数字，用数字/N，如果得到的值小于0.7即可无忧。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。3797人阅读
linux（10）
转自：//what-is-load-average/
一幅图秒懂LoadAverage（负载）
一、什么是Load Average？
系统负载（System Load）是系统CPU繁忙程度的度量，即有多少进程在等待被CPU调度（进程等待队列的长度）。
平均负载（Load Average）是一段时间内系统的平均负载，这个一段时间一般取1分钟、5分钟、15分钟。
二、如何查看Load？
top命令，w命令，uptime等命令都可以查看系统负载：
[shenjian@dev02 ~]$ uptime
13:53:39 up 130 days, &2:15, &1 user, &load average: 1.58, 2.58, 5.58
如上所示，dev02机器1分钟平均负载，5分钟平均负载，15分钟平均负载分别是1.58、2.58、5.58
三、Load的数值是什么含义？
把CPU比喻成一条（单核）马路，进程任务比喻成马路上跑着的汽车，Load则表示马路的繁忙程度：
Load小于1：表示完全不堵车，汽车在马路上跑得游刃有余：
Load&1，单核]
Load等于1：马路已经没有额外的资源跑更多的汽车了：
[Load==1，单核]
Load大于1：汽车都堵着等待进入马路：
[Load&1，单核]
如果有两个CPU，则表示有两条马路，此时即使Load大于1也不代表有汽车在等待：
[Load==2，双核，没有等待]
四、什么样的Load值得警惕（单核）？
Load & 0.7时：系统很闲，马路上没什么车，要考虑多部署一些服务
0.7 & Load & 1时：系统状态不错，马路可以轻松应对
Load == 1时：系统马上要处理不多来了，赶紧找一下原因
Load & 5时：马路已经非常繁忙了，进入马路的每辆汽车都要无法很快的运行
五、三个Load值要先看哪一个？
结合具体情况具体分析：
1）1分钟Load&5，5分钟Load&1，15分钟Load&1：短期内繁忙，中长期空闲，初步判断是一个“抖动”，或者是“拥塞前兆”
2）1分钟Load&5，5分钟Load&1，15分钟Load&1：短期内繁忙，中期内紧张，很可能是一个“拥塞的开始”
3）1分钟Load&5，5分钟Load&5，15分钟Load&5：短中长期都繁忙，系统“正在拥塞”
4）1分钟Load&1，5分钟Load&1，15分钟Load&5：短期内空闲，中长期繁忙，不用紧张，系统“拥塞正在好转”
六、Load总结
Load&1，单核]
[Load==1，单核]
[Load&1，单核]
[Load==2，双核]
希望上面一幅图对大家理解Load Average有帮助，赶快uptime一下，看一下自己系统的负载吧。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：359990次
积分：4016
积分：4016
排名：第7449名
原创：61篇
转载：57篇
评论：22条
(1)(4)(3)(1)(6)(7)(2)(3)(15)(15)(18)(7)(2)(27)(8)Linux主机load average的概念&&计算过程&&注意事项_服务器应用_Linux公社-Linux系统门户网站
你好，游客
Linux主机load average的概念&&计算过程&&注意事项
来源：Linux社区&
作者：slvher
最近开发的一个模块需要根据机房各节点的负载情况（如网卡IO、load average等指标）做任务调度，刚开始对Linux机器load average这项指标不是很清楚，经过调研，终于搞清楚了其计算方法和影响因素，作为笔记，记录于此。
1. load average
当在shell终端键入top命令时，默认情况下，在输出内容的第一行会有load average这项指标值，如下所示：
top - 19:10:32 up 626 days,& 4:58,& 1 user,& load average: 7.74, 5.62, 6.51Tasks: 181 total,&
8 running, 173 sleeping,&
0 stopped,&
0 zombieCpu(s):& 4.0% us,& 0.5% sy,& 0.0% ni, 95.4% id,& 0.0% wa,& 0.0% hi,& 0.0% si
同样，输入uptime命令，load average也会被输出：
19:15:10 up 129 days,& 5:12, 15 users,& load average: 0.01, 0.09, 0.05&
根据man uptime的说明可知，load average包含的3个值分别表示past 1, 5 and 15 minutes内的系统平均负载。
那么，这3个值是怎么计算出来的？下面从Linux源码中寻找答案。
2. linux机器load average的计算过程
wikipedia在对load的解释（参见）中，提到了linux系统对load的计算方法，为亲自验证，我check了linux源码（linux kernel 2.6.9）中的相关代码，自顶向下的验证过程如下。
在源码树kernel/timer.c文件中，计算系统load的函数代码如下:
// 源码树路径：kernel/timer.c/*&* Hmm.. Changed this, as the GNU make sources (load.c) seems to&* imply that avenrun[] is the standard name for this kind of thing.&* Nothing else seems to be standardized: the fractional size etc&* all seem to differ on different machines.&*&* Requires xtime_lock to access.&*/unsigned long avenrun[3];
/*&* calc_load - given tick count, update the avenrun load estimates.&* This is called while holding a write_lock on xtime_lock.&*/static inline void calc_load(unsigned long ticks){&unsigned long active_ /* fixed-point */&static int count = LOAD_FREQ;
&count -=&if (count & 0) {& count += LOAD_FREQ;& active_tasks = count_active_tasks();& CALC_LOAD(avenrun[0], EXP_1, active_tasks);& CALC_LOAD(avenrun[1], EXP_5, active_tasks);& CALC_LOAD(avenrun[2], EXP_15, active_tasks);&}}
从上面的代码可知，定义的数组avenrun[]包含3个元素，分别用于存放past 1, 5 and 15 minutes的load average值。calc_load则是具体的计算函数，其参数ticks表示采样间隔。函数体中，获取当前的活跃进程数（active tasks），然后以其为参数，调用CALC_LOAD分别计算3种load average。
沿着函数调用链，可以看到count_active_tasks()定义如下（也在kernel/timer.c文件中）：
/*& &* Nr of active tasks - counted in fixed-point numbers&*/static unsigned long count_active_tasks(void){&return (nr_running() + nr_uninterruptible()) * FIXED_1;}
由源码可见，count_active_tasks()返回当前的活跃进程数，其中活跃进程包括:1）当前正在运行的进程（nr_running）；2）不可中断的sleeping进程（如正在执行IO操作的被挂起进程）。
相关资讯 & & &
& (01/15/:32)
& (08/13/:56)
& (08/21/:43)
& (08/08/:48)
& (06/04/:29)
& (08/18/:21)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款