??xml version="1.0" encoding="utf-8" standalone="yes"?>
By Steve Mushero
Linux内核在性能斚w已经l历了很长一D|间的考验Q尤其是2.6/3.x内核。然而,在高IOQ尤其是|络斚w的情况下Q对中断的处理可能成为问题。我们已l?/span> 在拥有一个或多个饱和1Gbps|卡的高性能pȝ上发现过q个问题Q近来在有许多小包ƈ发(大约10000packets/secondQ超载的虚拟Z 也发Cq个问题?/span>
原因很清楚:在最单的模式中,内核通过g中断的方式来处理每个来自于网卡的包。但是随着 数据包速率的增长,带来的中断渐渐超q了单个cpu可处理的范围。单cpu概念很重要,pȝ理员对此往往认识不。在一个普通的4-16核的pȝ中,?/span> 为整?/span>cpu的用率?/span>6-25%左右q且pȝ看上d正常Q所以一个过载的内核很难被发玎ͼ。但是系l将q行很慢Qƈ且会在没有告警,没有dmesg?/span> 志,没有明显征兆的情况下严重丢包?/span>
但是你?/span>top查看多个cpu模式(q行topQ接着键入1)Ӟ%si 列(pȝ中断Q或?/span>mpstat命o?/span> irq?/span>(mpstat -P ALL 1)Q在一些繁忙的pȝ中你会发C断明昑־高,通过l进一?/span>mpstat使用Q你会看到哪?/span>cpu或者哪个设备存在问题?/span>
你需要一个较新版本的mpstatQ可以运?/span>-I 模式Q用以列?/span>irq负蝲Q运行如下命令:
mpstat -I SUM -P ALL 1
过5000/U?/span> 有点J忙Q?/span> 1?/span>-2?/span>/U相当高了?/span>
q行如下命o来确认那个设?/span>/目D负蝲Q?/span>
mpstat -I CPU -P ALL 1
q个输出很难被阅读,但是你可以跟t正的列用来确认哪个中断导致负载,例如Q?/span>15Q?/span>19Q?/span>995. 你也可以定义你想查看?/span>cpu
mpstat -I CPU -P 3 1 # 3 ?/span>top,htop中可以定位不同的cpu。(top?/span>mpstat都是?/span>0开始,htop是从1开始计敎ͼ
记录下中断数Q你可以查看中断表 Q?/span>"cat /proc/interrupts" 扑ֈmpstat's得到的数字,你可以发现是哪个讑֤在用中断。这个文件也指示了用该中断?/span>#可以告诉你是什么导致过载?/span>
需要做什么呢Q?/span>
首先Q确认你是否q行irqbalanceQ这个是nice守护q程它会自动?/span>cpu间扩展中断。在J忙的系l中很重要,其是两块网卡,因ؓ默认cpu0 处理所有中断,pȝ很容易过载?/span>irqbalance扩散q些中断用以降低负蝲。ؓ了性能最大化Q你可以手动qq些中断套接字和超U程׃n内核?/span> 散,但是通常没必要这么麻烦?/span>
但是即扩展了中断,某块|卡q是可能D某一?/span>cpuq蝲。这取决于你的网卡和驱动Q但通常有两U有效的Ҏ来防止这L事情发生?/span>
W一U是多网卡队列,有些Intel|卡可以这么做。如果他们有4个队列,可以有四个cpu内核同时处理不同的中断用以分散负载。通常驱动会自动这么做Q你也可以通过mpstat命o来确认?/span>
W二U,q且通常也是更加重要的,|卡驱动选项——'IRQ coalescing'Q中断请求合q。这个选项有着强大的功能,允许|卡在调用中断请求前~存C数据包,从而ؓpȝ节约大量的时间和负蝲。D个例子: 如果|卡~存10个包Q那?/span>cpu负蝲大U降?/span>90%。这个功能通常?/span>ethtool工具来控Ӟ使用'-c/-C'参数Q但是有些驱动要求在驱动初次 加蝲时就做好相关讄。如何设|需要查看本机文档。D个例子,有些|卡Q譬如我们用的Intel|卡Q就?/span>automatic模式可以Ҏ负蝲自动做到 最优化?/span>
最后,像我们在虚拟机中看到的一些驱动,它们不支持多队列或者中断请求合q。这U情况下Q一旦处理中断的cpuJ忙Q就会生性能瓉Q除非你更换讑֤或者驱动?/span>
q是一个复杂的区域Qƈ不广Zh知,但有些不错的技术真的可以提高繁忙系l的性能。此外,一些额外的针对性监控,可以帮助到查扑֒诊断q些难以发现的问题?/span>
本文?/span> Steve Mushero, 联合创始人兼首席执行官发表于2012q?/span>4?/span>25?/span>
作者简介:
Steve Mushero先生拥有过20q在各行业的Q国际性的技术管理经验。他曄担Q土豆|的首席技术官Q负?/span>Intermind的高U管理系l,?/span>Beyond Access Communications ?/span> AirReview担Q首席架构师。他?/span>Managing White-Collar Job Migration to Asia一书的作者,多项专利的发明者?/span>
云络|络U技Q上P有限公司持有最l解释权
转自http://wenku.baidu.com/view/38a764b8f121dd36a32d828e.html
1. 基本使用
$iostat -d -k 1 10
参数 -d 表示Q显C备(盘Q用状态;-k某些使用block为单位的列强制用Kilobytes为单位;1 10表示Q数据显C每?U刷Cơ,共显C?0ơ?/p>
$iostat -d -k 1 10 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 39.29 21.14 1.44 441339807 29990031 sda1 0.00 0.00 0.00 1623 523 sda2 1.32 1.43 4.54 29834273 94827104 sda3 6.30 0.85 24.95 17816289 520725244 sda5 0.85 0.46 3.40 9543503 70970116 sda6 0.00 0.00 0.00 550 236 sda7 0.00 0.00 0.00 406 0 sda8 0.00 0.00 0.00 406 0 sda9 0.00 0.00 0.00 406 0 sda10 60.68 18.35 71.43 383002263 1490928140 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 327.55 5159.18 102.04 5056 100 sda1 0.00 0.00 0.00 0 0
tpsQ该讑֤每秒的传输次敎ͼIndicate the number of transfers per second that were issued to the device.Q?#8220;一ơ传?#8221;意思是“一ơI/Oh”。多个逻辑h可能会被合ƈ?#8220;一ơI/Oh”?#8220;一ơ传?#8221;h的大是未知的?/p>
kB_read/sQ每U从讑֤Qdrive expressedQ读取的数据量;kB_wrtn/sQ每U向讑֤Qdrive expressedQ写入的数据量;kB_readQ读取的L据量QkB_wrtnQ写入的L量数据量Q这些单位都为Kilobytes?/p>
上面的例子中Q我们可以看到磁盘sda以及它的各个分区的统计数据,当时l计的磁盘总TPS?9.29Q下面是各个分区的TPS。(因ؓ是瞬间|所以总TPSq不严格{于各个分区TPS的dQ?/p>
2. -x 参数
使用-x参数我们可以获得更多l计信息?/p>
iostat -d -x -k 1 10 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 1.56 28.31 7.80 31.49 42.51 2.92 21.26 1.46 1.16 0.03 0.79 2.62 10.28 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 2.00 20.00 381.00 7.00 12320.00 216.00 6160.00 108.00 32.31 1.75 4.50 2.17 84.20
rrqm/sQ每U这个设备相关的dh有多被Merge了(当系l调用需要读取数据的时候,VFS请求发到各个FSQ如果FS发现不同的读取请求读取的是相同Block的数据,FS会将q个h合ƈMergeQ;wrqm/sQ每U这个设备相关的写入h有多被Merge了?/p>
rsec/sQ每U读取的扇区敎ͼwsec/Q每U写入的扇区数。r/sQThe number of read requests that were issued to the device per secondQw/sQThe number of write requests that were issued to the device per secondQ?/p>
awaitQ每一个IOh的处理的q_旉Q单位是微秒毫秒Q。这里可以理解ؓIO的响应时_一般地pȝIO响应旉应该低于5msQ如果大?0ms比较大了?/p>
%utilQ在l计旉内所有处理IO旉Q除以dl计旉。例如,如果l计间隔1U,该设备有0.8U在处理IOQ?.2U闲|,那么该设备的%util = 0.8/1 = 80%Q所以该参数暗示了设备的J忙E度。一般地Q如果该参数?00%表示讑֤已经接近满负药行了Q当然如果是多磁盘,即%util?00%Q因为磁盘的q发能力Q所以磁盘用未必就C瓉Q?/p>
3. -c 参数
iostatq可以用来获取cpu部分状态|
iostat -c 1 10 avg-cpu: %user %nice %sys %iowait %idle 1.98 0.00 0.35 11.45 86.22 avg-cpu: %user %nice %sys %iowait %idle 1.62 0.00 0.25 34.46 63.67
4. 常见用法
$iostat -d -k 1 10 #查看TPS和吞吐量信息 iostat -d -x -k 1 10 #查看讑֤使用率(%utilQ、响应时_awaitQ?iostat -c 1 10 #查看cpu状?
5. 实例分析
$$iostat -d -k 1 |grep sda10 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda10 60.72 18.95 71.53 395637647 1493241908 sda10 299.02 4266.67 129.41 4352 132 sda10 483.84 4589.90 4117.17 4544 4076 sda10 218.00 3360.00 100.00 3360 100 sda10 546.00 8784.00 124.00 8784 124 sda10 827.00 13232.00 136.00 13232 136
上面看到Q磁盘每U传输次数^均约400Q每U磁盘读取约5MBQ写入约1MB?/p>
iostat -d -x -k 1 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 1.56 28.31 7.84 31.50 43.65 3.16 21.82 1.58 1.19 0.03 0.80 2.61 10.29 sda 1.98 24.75 419.80 6.93 13465.35 253.47 6732.67 126.73 32.15 2.00 4.70 2.00 85.25 sda 3.06 41.84 444.90 54.08 14204.08 2048.98 7102.04 1024.49 32.57 2.10 4.21 1.85 92.24
可以看到盘的^均响应时?lt;5msQ磁盘用率>80。磁盘响应正常,但是已经很繁忙了?/p>
参考文献:
通过下面的几个部分的了解Q可以一步一步的扑ևLoad Average在压力测试中真正的作用?/span>
CPU旉?/span>
Z提高E序执行效率Q大家在很多应用中都采用了多U程模式Q这样可以将原来的序列化执行变ؓq行执行QQ务的分解以及q行执行能够极大地提高程序的q行效率。但q都是代码别的表现Q而硬件是如何支持的呢Q那p?/span>CPU的时间片模式来说明这一切。程序的M指o的执行往往都会要竞?/span>CPUq个最宝贵的资源,不论你的E序分成了多个U程L行不同的dQ他们都必须排队{待获取q个资源来计和处理命o。先看看?/span>CPU的情c下面两图描qC旉片模式和非时间片模式下的U程执行的情况:
?/span> 1 非时间片U程执行情况
?/span> 2 非时间片U程执行情况
在图一中可以看刎ͼMU程如果都排队等?/span>CPU资源的获取,那么所谓的多线E就没有M实际意义。图二中?/span>CPU Manager只是我虚拟的一个角Ԍ由它来分配和理CPU的用状况,此时多线E将会在q行q程中都有机会得?/span>CPU资源Q也真正实现了在?/span>CPU的情况下实现多线Eƈ行处理?/span>
?/span>CPU的情况只是单CPU的扩展,当所有的CPU都满负荷q作的时候,׃Ҏ一?/span>CPU采用旉片的方式来提高效率?/span>
?/span>Linux的内核处理过E中Q每一个进E默认会有一个固定的旉片来执行命oQ默认ؓ1/100U)Q这D|间内q程被分配到CPUQ然后独占用。如果用完Q同时未到时间片的规定时_那么׃动放?/span>CPU的占用,如果到时间片未完成工作Q那?/span>CPU的用权也会被收回,q程会被中断挂L待下一个时间片?/span>
CPU利用率和Load Average的区?/span>
压力试不仅需要对业务场景的ƈ发用L压力参数作模拟,同时也需要在压力试q程中随时关注机器的性能情况Q来保压力试的有效性。当服务器长期处于一U超负荷的情况下q行Q所能接收的压力q不是我们所认ؓ的可接受的压力。就好比目l理在给一个h估工作量的时候,每天都让q个人工?/span>12个小Ӟ那么所制定的项目计划就不是一个合理的计划Q那个hq早会垮掉,而媄响整体的目q度?/span>
CPU利用率在q去常常被我们这些外行认为是判断机器是否已经C满负L一个标准,看到50%-60%的用率p为机器就已经压到了界了?/span>CPU利用率,思义是对于CPU的用状况,q是对一个时间段?/span>CPU使用状况的统计,通过q个指标可以看出在某一个时间段?/span>CPU被占用的情况Q如果被占用旉很高Q那么就需要考虑CPU是否已经处于负药作,长期负药作对于机器本w来说是一U损宻I因此必须?/span>CPU的利用率控制在一定的比例下,以保证机器的正常q作?/span>
Load Average?/span>CPU?/span>LoadQ它所包含的信息不?/span>CPU的用率状况Q而是在一D|间内CPU正在处理以及{待CPU处理的进E数之和的统计信息,也就?/span>CPU使用队列的长度的l计信息。ؓ什么要l计q个信息Q这个信息的对于压力试的媄响究竟是怎么LQ那通过一个类比来解释CPU利用率和Load Average的区别以及对于压力测试的指导意义?/span>
我们?/span>CPUq比ؓ电话亭,每一个进E都是一个需要打电话的h。现在一共有4个电话亭Q就好比我们的机器有4核)Q有10个h需要打电话。现在用电话的规则是管理员会按照顺序给每一个h轮流分配1分钟的用电话时_如果使用者在1分钟内用完毕,那么可以立刻电话用权q还l管理员Q如果到?/span>1分钟电话使用者还没有使用完毕Q那么需要重新排队,{待再次分配使用?/span>
?/span> 3 电话使用场景
上图中对于用电话的用户又作了一ơ分c,1min的代表这些用者占用电话时间小于等?/span>1minQ?/span>2min表示使用者占用电话时间小于等?/span>2minQ以此类推。根据电话用规则,1min的用户只需要得Cơ分配即可完成通话Q而其他两cȝ户需要排队两ơ到三次?/span>
电话的利用率 = sum (active use cpu time)/period
每一个分配到电话的用者用电话时间的d去除以统计的旉Dc这里需要注意的是是使用电话的时间d(sum(active use cpu time))Q这与占用时间的d(sum(occupy cpu time))是有区别的。(例如一个用户得C一分钟的用权Q在10U钟内打了电话,然后L询号码本׃20U钟Q再用剩下的30U打了另一个电话,那么占用了电?/span>1分钟Q实际只是用了40U)
电话?/span>Average Load体现的是在某一l计旉D内Q所有用电话的人加上等待电话分配的Z个^均统计?/span>
电话利用率的l计能够反映的是电话被用的情况Q当电话长期处于被用而没有的到够的旉休息间歇Q那么对于电话硬件来说是一U超负荷的运作,需要调整用频度。而电?/span>Average Load却从另一个角度来展现对于电话使用状态的描述Q?/span>Average Load高说明对于电话资源的竞争越Ȁ烈,电话资源比较短缺。对于资源的甌和维护其实也是需要很大的成本Q所以在q种?/span>Average Load的情况下电话资源的长?#8220;热竞?#8221;也是对于g的一U损実?/span>
低利用率的情况下是否会有?/span>Load Average的情况生呢Q理解占有时间和使用旉可以知道,当分配时间片以后Q是否用完全取决于使用者,因此完全可能出现低利用率?/span>Load Average的情c由此来看,仅仅?/span>CPU的用率来判?/span>CPU是否处于一U超负荷的工作状态还是不够的Q必ȝ?/span>Load Average来全局的看CPU的用情况和甌情况?/span>
所以回q头来再看测试部对于Load Average的要求,在我们机器ؓ8?/span>CPU的情况下Q控制在10 Load左右Q也是每一?/span>CPU正在处理一个请求,同时q有2个在{待处理。看了看|上很多人的介绍一般来?/span>Load单的计算是2* CPU个数减去1-2左右Q这个只是网上看来的Q未必是一个标准)?/span>
补充几点Q?/span>
1Q对?/span>CPU利用率和CPU Load Average的结果来判断性能问题。首先低CPU利用率不表明CPU不是瓉Q竞?/span>CPU的队列长期保持较长也?/span>CPU负L一U表现。对于应用来说可能会去花旉?/span>I/O,Socket{方面,那么可以考虑是否后这些硬件的速度影响了整体的效率?/span>
q里最好的h范例是我在试中发现的一个现象:SIP当前在处理过E中Qؓ了提高处理效率,控制策略以及计C息都攄?/span>Memcached Cache里面Q当我将Memcached Cache配置扩容一倍以后,CPU的利用率以及Load都有所下降Q其实也是在处理Q务的q程中,{待Socket的返回对?/span>CPU的竞争也产生了媄响?/span>
2Q未来多CPU~程的重要性。现在服务器?/span>CPU都是?/span>CPU了,我们的服务器处理能力已经不再按照摩尔定律来发展。就我上面提到的电话亭场景来看,对于三种不同旉需求的用户来说Q采用不同的分配序Q我们可看到?/span>Load Average׃有不同。假设我们统?/span>Load的时间段?/span>2分钟Q如果将电话分配的顺序按照:1min的用P2min的用P3min的用h分配Q那么我们的Load Average会最低,采用其他序会有不同的l果。所以未来的?/span>CPU~程可以更好的提?/span>CPU的利用率Q让E序跑的更快?/span>
以上所提到的内Ҏ必都是很准确或者正,如果有Q何的偏差也请大家指出Q可以纠正一些不清楚的概c?br />
原文转至文初的blogjavaQ?/span>http://www.aygfsteel.com/cenwenchu/archive/2008/06/30/211712.html