By Steve Mushero

Linux内核在性能方面已经经历了很长一段时间的考验，尤其是2.6/3.x内核。然而，在高IO，尤其是网络方面的情况下，对中断的处理可能成为问题。我们已经 在拥有一个或多个饱和1Gbps网卡的高性能系统上发现过这个问题，近来在有许多小包并发（大约10000packets/second）超载的虚拟机上 也发现了这个问题。

原因很清楚：在最简单的模式中，内核通过硬件中断的方式来处理每个来自于网卡的包。但是随着 数据包速率的增长，带来的中断渐渐超过了单个cpu可处理的范围。单cpu概念很重要，系统管理员对此往往认识不足。在一个普通的4-16核的系统中，因 为整体cpu的使用率在6-25%左右并且系统看上去很正常，所以一个过载的内核很难被发现，。但是系统将运行很慢，并且会在没有告警，没有dmesg日 志，没有明显征兆的情况下严重丢包。

但是你使用top查看多个cpu模式(运行top，接着键入1)时，%si 列（系统中断）或者mpstat命令中 irq列(mpstat -P ALL 1)，在一些繁忙的系统中你会发现中断明显很高，通过经进一步mpstat使用，你会看到哪个cpu或者哪个设备存在问题。

你需要一个较新版本的mpstat，可以运行-I 模式，用以列出irq负载，运行如下命令：

mpstat -I SUM -P ALL 1

超过5000/秒 有点繁忙， 1万-2万/秒相当高了。

运行如下命令来确认那个设备/项目导致负载：

mpstat -I CPU -P ALL 1

这个输出很难被阅读，但是你可以跟踪正确的列用来确认哪个中断导致负载，例如：15，19，995. 你也可以定义你想查看的cpu

mpstat -I CPU -P 3 1 # 3 在top,htop中可以定位不同的cpu。（top和mpstat都是从0开始，htop是从1开始计数）

记录下中断数，你就可以查看中断表 ，"cat /proc/interrupts" 找到mpstat's得到的数字，你可以发现是哪个设备在使用中断。这个文件也指示了使用该中断的#可以告诉你是什么导致过载。

需要做什么呢？

首先，确认你是否运行irqbalance，这个是nice守护进程它会自动在cpu间扩展中断。在繁忙的系统中很重要，尤其是两块网卡，因为默认cpu0 将处理所有中断，系统很容易过载。irqbalance扩散这些中断用以降低负载。为了性能最大化，你可以手动平衡这些中断将套接字和超线程共享内核分 散，但是通常没必要这么麻烦。

但是即使扩展了中断，某块网卡还是可能导致某一个cpu过载。这取决于你的网卡和驱动，但通常有两种有效的方法来防止这样的事情发生。

第一种是多网卡队列，有些Intel网卡就可以这么做。如果他们有4个队列，就可以有四个cpu内核同时处理不同的中断用以分散负载。通常驱动会自动这么做，你也可以通过mpstat命令来确认。

第二种，并且通常也是更加重要的，网卡驱动选项——'IRQ coalescing'，中断请求合并。这个选项有着强大的功能，允许网卡在调用中断请求前缓存数个数据包，从而为系统节约大量的时间和负载。举个例子： 如果网卡缓存10个包，那么cpu负载将大约降低90%。这个功能通常用ethtool工具来控制，使用'-c/-C'参数，但是有些驱动要求在驱动初次 加载时就做好相关设置。如何设置需要查看本机文档。举个例子，有些网卡，譬如我们使用的Intel网卡，就有automatic模式可以根据负载自动做到 最优化。

最后，就像我们在虚拟机中看到的一些驱动，它们不支持多队列或者中断请求合并。这种情况下，一旦处理中断的cpu繁忙，就会产生性能瓶颈，除非你更换设备或者驱动。

这是一个复杂的区域，并不广为人知，但有些不错的技术真的可以提高繁忙系统的性能。此外，一些额外的针对性监控，可以帮助到查找和诊断这些难以发现的问题。

本文由 Steve Mushero, 联合创始人兼首席执行官发表于2012年4月25日

作者简介：

Steve Mushero

云络创始人，首席技术官

Steve Mushero先生拥有超过20年在各行业的，国际性的技术管理经验。他曾经担任土豆网的首席技术官，负责Intermind的高级管理系统，在Beyond Access Communications 和 AirReview担任首席架构师。他是Managing White-Collar Job Migration to Asia一书的作者，多项专利的发明者。

云络网络科技（上海）有限公司持有最终解释权

转自http://wenku.baidu.com/view/38a764b8f121dd36a32d828e.html

1. 基本使用

$iostat -d -k 1 10
 

参数 -d 表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；1 10表示，数据显示每隔1秒刷新一次，共显示10次。

$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 
 

tps：该设备每秒的传输次数（Indicate the number of transfers per second that were issued to the device.）。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的。

kB_read/s：每秒从设备（drive expressed）读取的数据量；kB_wrtn/s：每秒向设备（drive expressed）写入的数据量；kB_read：读取的总数据量；kB_wrtn：写入的总数量数据量；这些单位都为Kilobytes。

上面的例子中，我们可以看到磁盘sda以及它的各个分区的统计数据，当时统计的磁盘总TPS是39.29，下面是各个分区的TPS。（因为是瞬间值，所以总TPS并不严格等于各个分区TPS的总和）

2. -x 参数

使用-x参数我们可以获得更多统计信息。

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/s：每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）；wrqm/s：每秒这个设备相关的写入请求有多少被Merge了。

rsec/s：每秒读取的扇区数；wsec/：每秒写入的扇区数。r/s：The number of read requests that were issued to the device per second；w/s：The number of write requests that were issued to the device per second；

await：每一个IO请求的处理的平均时间（单位是微秒毫秒）。这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。

%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。

3. -c 参数

iostat还可以用来获取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      #查看设备使用率（%util）、响应时间（await） 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
 

上面看到，磁盘每秒传输次数平均约400；每秒磁盘读取约5MB，写入约1MB。

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
 

可以看到磁盘的平均响应时间<5ms，磁盘使用率>80。磁盘响应正常，但是已经很繁忙了。

参考文献：

1. Linux man iostat
2. How Linux iostat computes its results
3. Linux iostat
   
   原文地址：http://www.orczhou.com/index.php/2010/03/iostat-detail/

       通过下面的几个部分的了解，可以一步一步的找出Load Average在压力测试中真正的作用。

CPU时间片

       为了提高程序执行效率，大家在很多应用中都采用了多线程模式，这样可以将原来的序列化执行变为并行执行，任务的分解以及并行执行能够极大地提高程序的运行效率。但这都是代码级别的表现，而硬件是如何支持的呢？那就要靠CPU的时间片模式来说明这一切。程序的任何指令的执行往往都会要竞争CPU这个最宝贵的资源，不论你的程序分成了多少个线程去执行不同的任务，他们都必须排队等待获取这个资源来计算和处理命令。先看看单CPU的情况。下面两图描述了时间片模式和非时间片模式下的线程执行的情况：

图 1 非时间片线程执行情况

图 2 非时间片线程执行情况

       在图一中可以看到，任何线程如果都排队等待CPU资源的获取，那么所谓的多线程就没有任何实际意义。图二中的CPU Manager只是我虚拟的一个角色，由它来分配和管理CPU的使用状况，此时多线程将会在运行过程中都有机会得到CPU资源，也真正实现了在单CPU的情况下实现多线程并行处理。

       多CPU的情况只是单CPU的扩展，当所有的CPU都满负荷运作的时候，就会对每一个CPU采用时间片的方式来提高效率。

       在Linux的内核处理过程中，每一个进程默认会有一个固定的时间片来执行命令（默认为1/100秒），这段时间内进程被分配到CPU，然后独占使用。如果使用完，同时未到时间片的规定时间，那么就主动放弃CPU的占用，如果到时间片尚未完成工作，那么CPU的使用权也会被收回，进程将会被中断挂起等待下一个时间片。

CPU利用率和Load Average的区别

       压力测试不仅需要对业务场景的并发用户等压力参数作模拟，同时也需要在压力测试过程中随时关注机器的性能情况，来确保压力测试的有效性。当服务器长期处于一种超负荷的情况下运行，所能接收的压力并不是我们所认为的可接受的压力。就好比项目经理在给一个人估工作量的时候，每天都让这个人工作12个小时，那么所制定的项目计划就不是一个合理的计划，那个人迟早会垮掉，而影响整体的项目进度。

CPU利用率在过去常常被我们这些外行认为是判断机器是否已经到了满负荷的一个标准，看到50%-60%的使用率就认为机器就已经压到了临界了。CPU利用率，顾名思义就是对于CPU的使用状况，这是对一个时间段内CPU使用状况的统计，通过这个指标可以看出在某一个时间段内CPU被占用的情况，如果被占用时间很高，那么就需要考虑CPU是否已经处于超负荷运作，长期超负荷运作对于机器本身来说是一种损害，因此必须将CPU的利用率控制在一定的比例下，以保证机器的正常运作。

Load Average是CPU的Load，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。为什么要统计这个信息，这个信息的对于压力测试的影响究竟是怎么样的，那就通过一个类比来解释CPU利用率和Load Average的区别以及对于压力测试的指导意义。

我们将CPU就类比为电话亭，每一个进程都是一个需要打电话的人。现在一共有4个电话亭（就好比我们的机器有4核），有10个人需要打电话。现在使用电话的规则是管理员会按照顺序给每一个人轮流分配1分钟的使用电话时间，如果使用者在1分钟内使用完毕，那么可以立刻将电话使用权返还给管理员，如果到了1分钟电话使用者还没有使用完毕，那么需要重新排队，等待再次分配使用。

图 3 电话使用场景

       上图中对于使用电话的用户又作了一次分类，1min的代表这些使用者占用电话时间小于等于1min，2min表示使用者占用电话时间小于等于2min，以此类推。根据电话使用规则，1min的用户只需要得到一次分配即可完成通话，而其他两类用户需要排队两次到三次。

       电话的利用率 = sum (active use cpu time)/period

每一个分配到电话的使用者使用电话时间的总和去除以统计的时间段。这里需要注意的是是使用电话的时间总和(sum(active use cpu time))，这与占用时间的总和(sum(occupy cpu time))是有区别的。（例如一个用户得到了一分钟的使用权，在10秒钟内打了电话，然后去查询号码本花了20秒钟，再用剩下的30秒打了另一个电话，那么占用了电话1分钟，实际只是使用了40秒）

电话的Average Load体现的是在某一统计时间段内，所有使用电话的人加上等待电话分配的人一个平均统计。

电话利用率的统计能够反映的是电话被使用的情况，当电话长期处于被使用而没有的到足够的时间休息间歇，那么对于电话硬件来说是一种超负荷的运作，需要调整使用频度。而电话Average Load却从另一个角度来展现对于电话使用状态的描述，Average Load越高说明对于电话资源的竞争越激烈，电话资源比较短缺。对于资源的申请和维护其实也是需要很大的成本，所以在这种高Average Load的情况下电话资源的长期“热竞争”也是对于硬件的一种损害。

低利用率的情况下是否会有高Load Average的情况产生呢？理解占有时间和使用时间就可以知道，当分配时间片以后，是否使用完全取决于使用者，因此完全可能出现低利用率高Load Average的情况。由此来看，仅仅从CPU的使用率来判断CPU是否处于一种超负荷的工作状态还是不够的，必须结合Load Average来全局的看CPU的使用情况和申请情况。

所以回过头来再看测试部对于Load Average的要求，在我们机器为8个CPU的情况下，控制在10 Load左右，也就是每一个CPU正在处理一个请求，同时还有2个在等待处理。看了看网上很多人的介绍一般来说Load简单的计算就是2* CPU个数减去1-2左右（这个只是网上看来的，未必是一个标准）。

补充几点：

1．对于CPU利用率和CPU Load Average的结果来判断性能问题。首先低CPU利用率不表明CPU不是瓶颈，竞争CPU的队列长期保持较长也是CPU超负荷的一种表现。对于应用来说可能会去花时间在I/O,Socket等方面，那么可以考虑是否后这些硬件的速度影响了整体的效率。

这里最好的样板范例就是我在测试中发现的一个现象：SIP当前在处理过程中，为了提高处理效率，将控制策略以及计数信息都放置在Memcached Cache里面，当我将Memcached Cache配置扩容一倍以后，CPU的利用率以及Load都有所下降，其实也就是在处理任务的过程中，等待Socket的返回对于CPU的竞争也产生了影响。

2．未来多CPU编程的重要性。现在服务器的CPU都是多CPU了，我们的服务器处理能力已经不再按照摩尔定律来发展。就我上面提到的电话亭场景来看，对于三种不同时间需求的用户来说，采用不同的分配顺序，我们可看到的Load Average就会有不同。假设我们统计Load的时间段为2分钟，如果将电话分配的顺序按照：1min的用户，2min的用户，3min的用户来分配，那么我们的Load Average将会最低，采用其他顺序将会有不同的结果。所以未来的多CPU编程可以更好的提高CPU的利用率，让程序跑的更快。

以上所提到的内容未必都是很准确或者正确，如果有任何的偏差也请大家指出，可以纠正一些不清楚的概念。


原文转至文初的blogjava：http://www.blogjava.net/cenwenchu/archive/2008/06/30/211712.html