性能优化：

  就是找到系统处理中的瓶颈以及去除这些的过程,性能优化其实是对OS 各子系统达到一种平衡的定义,这些子系统包括了:

1. CPU
2. Memory
3. IO
4. Network

     这些子系统之间关系是相互彼此依赖的,任何一个高负载都会导致其他子系统出现问题.比如:

1. 大量的页调入请求导致内存队列的拥塞
2. 网卡的大吞吐量可能导致更多的 CPU开销
3. 大量的CPU开销又会尝试更多的内存使用请求
4. 大量来自内存的磁盘写请求可能导致更多的 CPU 以及 IO问题

   所以要对一个系统进行优化,查找瓶颈来自哪个方面是关键,虽然看似是某一个子系统出现问题,其实有可能是别的子系统导致的.
1.1 确定应用类型
  基于需要理解该从什么地方来入手优化瓶颈,首先重要的一点,就是理解并分析当前系统的特点,多数系统所跑的应用类型,主要为2种:

1. IO Bound(译注:IO 范畴): 在这个范畴中的应用,一般都是高负荷的内存使用以及存储系统,这实际上表示IO 范畴的应用,就是一个大量数据处理的过程.IO 范畴的应用不对CPU以及网络发起更多请求(除非类似NAS这样的网络存储硬件).IO 范畴的应用通常使用CPU 资源都是为了产生IO 请求以及进入到内核调度的sleep 状态.通常数据库软件(译注:mysql,oracle等)被认为是IO 范畴的应用类型.
2. CPU Bound(译注:CPU 范畴): 在这个范畴中的应用,一般都是高负荷的CPU 占用. CPU 范畴的应用,就是一个批量处理CPU 请求以及数学计算的过程.通常web server,mail server,以及其他类型服务被认为是CPU 范畴的应用类型.

1.2 确定基准线统计
   系统利用率情况,一般随管理员经验以及系统本身用途来决定.唯一要清楚的就是,系统优化希望达成什么效果,以及哪些方面是需要优化,还有参考值是什么?因此就建立一个基准线,这个统计数据必须是系统可用性能状态值,用来比较不可用性能状态值.
在以下例子中,1个系统性能的基准线快照,用来比较当高负荷时的系统性能快照.
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 0 138592 17932 126272 214244 0 0 1 18 109 19 2 1 1 96
0 0 138592 17932 126272 214244 0 0 0 0 105 46 0 1 0 99
0 0 138592 17932 126272 214244 0 0 0 0 198 62 40 14 0 45
0 0 138592 17932 126272 214244 0 0 0 0 117 49 0 0 0 100
0 0 138592 17924 126272 214244 0 0 0 176 220 938 3 4 13 80
0 0 138592 17924 126272 214244 0 0 0 0 358 1522 8 17 0 75
1 0 138592 17924 126272 214244 0 0 0 0 368 1447 4 24 0 72
0 0 138592 17924 126272 214244 0 0 0 0 352 1277 9 12 0 79
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 0 145940 17752 118600 215592 0 1 1 18 109 19 2 1 1 96
2 0 145940 15856 118604 215652 0 0 0 468 789 108 86 14 0 0
3 0 146208 13884 118600 214640 0 360 0 360 498 71 91 9 0 0
2 0 146388 13764 118600 213788 0 340 0 340 672 41 87 13 0 0
2 0 147092 13788 118600 212452 0 740 0 1324 620 61 92 8 0 0
2 0 147360 13848 118600 211580 0 720 0 720 690 41 96 4 0 0
2 0 147912 13744 118192 210592 0 720 0 720 605 44 95 5 0 0
2 0 148452 13900 118192 209260 0 372 0 372 639 45 81 19 0 0
2 0 149132 13692 117824 208412 0 372 0 372 457 47 90 10 0 0
        从上面第一个结果可看到,最后一列(id) 表示的是空闲时间,我们可以看到,在基准线统计时,CPU 的空闲时间在79% - 100%.在第二个结果可看到,系统处于100%的占用率以及没有空闲时间.从这个比较中,我们就可以确定是否是CPU 使用率应该被优化.
2.0 CPU 介绍
  CPU 利用率主要依赖于是什么资源在试图存取.内核调度器将负责调度2种资源种类:线程(单一或者多路)和中断.调度器去定义不同资源的不同优先权.以下列表从优先级高到低排列:

1. Interrupts(译注:中断) - 设备通知内核,他们完成一次数据处理的过程.例子,当一块网卡设备递送网络数据包或者一块硬件提供了一次IO 请求.
2. Kernel(System) Processes(译注:内核处理过程) - 所有内核处理过程就是控制优先级别.
3. User Processes(译注:用户进程) - 这块涉及"userland".所有软件程序都运行在这个user space.这块在内核调度机制中处于低优先级.

  从上面,我们可以看出内核是怎样管理不同资源的.还有几个关键内容需要介绍,以下部分就将介绍context(译注:上下文切换),run queues(译注:运行队列)以及utilization(译注:利用率).
2.1 上下文切换
  多数现代处理器都能够运行一个进程(单一线程)或者线程.多路超线程处理器有能力运行多个线程.然而,Linux 内核还是把每个处理器核心的双核心芯片作为独立的处理器.比如,以Linux 内核的系统在一个双核心处理器上,是报告显示为两个独立的处理器.
一个标准的Linux 内核可以运行50 至 50,000 的处理线程.在只有一个CPU时,内核将调度并均衡每个进程线程.每个线程都分配一个在处理器中被开销的时间额度.一个线程要么就是获得时间额度或已抢先获得一些具有较高优先级(比如硬件中断),其中较高优先级的线程将从区域重新放置回处理器的队列中.这种线程的转换关系就是我们提到的上下文切换.
  每次内核的上下文切换,资源被用于关闭在CPU寄存器中的线程和放置在队列中.系统中越多的上下文切换,在处理器的调度管理下,内核将得到更多的工作.
2.2 运行队列
   每个CPU 都维护一个线程的运行队列.理论上,调度器应该不断的运行和执行线程.进程线程不是在sleep 状态中(译注:阻塞中和等待IO中)或就是在可运行状态中.如果CPU 子系统处于高负荷下,那就意味着内核调度将无法及时响应系统请求.导致结果,可运行状态进程拥塞在运行队列里.当运行队列越来越巨大,进程线程将花费更多的时间获取被执行.
  比较流行的术语就是"load",它提供当前运行队列的详细状态.系统 load 就是指在CPU 队列中有多少数目的线程,以及其中当前有多少进程线程数目被执行的组合.如果一个双核系统执行了2个线程,还有4个在运行队列中,则 load 应该为 6. top 这个程序里显示的load averages 是指1,5,15 分钟以内的load 情况.
2.3 CPU 利用率
  CPU 利用率就是定义CPU 使用的百分比.评估系统最重要的一个度量方式就是CPU 的利用率.多数性能监控工具关于CPU 利用率的分类有以下几种:

1. User Time(译注:用户进程时间) - 关于在user space中被执行进程在CPU 开销时间百分比.
2. System Time(译注:内核线程以及中断时间) - 关于在kernel space中线程和中断在CPU 开销时间百分比.
3. Wait IO(译注:IO 请求等待时间) - 所有进程线程被阻塞等待完成一次IO 请求所占CPU 开销idle的时间百分比.
4. Idle(译注:空闲) - 一个完整空闲状态的进程在CPU 处理器中开销的时间百分比.

3.0 CPU 性能监控
  理解运行队列,利用率,上下文切换对怎样CPU 性能最优化之间的关系.早期提及到,性能是相对于基准线数据的.在一些系统中,通常预期所达到的性能包括:

1. Run Queues - 每个处理器应该运行队列不超过1-3 个线程.例子,一个双核处理器应该运行队列不要超过6 个线程.
2. CPU Utiliation - 如果一个CPU 被充分使用,利用率分类之间均衡的比例应该是
3. 65% - 70% User Time
4. 30% - 35% System Time
5. 0% - 5% Idle Time

  Context Switches - 上下文切换的数目直接关系到CPU 的使用率,如果CPU 利用率保持在上述均衡状态时,大量的上下文切换是正常的.
  很多Linux 上的工具可以得到这些状态值,首先就是 vmstat 和 top 这2个工具.
3.1 vmstat 工具的使用
  vmstat 工具提供了一种低开销的系统性能观察方式.因为 vmstat 本身就是低开销工具,在非常高负荷的服务器上,你需要查看并监控系统的健康情况,在控制窗口还是能够使用vmstat 输出结果.这个工具运行在2种模式下:average 和 sample 模式.sample 模式通过指定间隔时间测量状态值.这个模式对于理解在持续负荷下的性能表现,很有帮助.下面就是
vmstat 运行1秒间隔的示例:
# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 104300 16800 95328 72200 0 0 5 26 7 14 4 1 95 0
0 0 104300 16800 95328 72200 0 0 0 24 1021 64 1 1 98 0
0 0 104300 16800 95328 72200 0 0 0 0 1009 59 1 1 98 0
Table 1: The vmstat CPU statistics

Field Description （显示参数定义）

e.st列一般不关注，虚拟机占用的时间百分比。

3.2 案例学习:持续的CPU 利用率
在这个例子中,这个系统被充分利用
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
3 0 206564 15092 80336 176080 0 0 0 0 718 26 81 19 0 0
2 0 206564 14772 80336 176120 0 0 0 0 758 23 96 4 0 0
1 0 206564 14208 80336 176136 0 0 0 0 820 20 96 4 0 0
1 0 206956 13884 79180 175964 0 412 0 2680 1008 80 93 7 0 0
2 0 207348 14448 78800 175576 0 412 0 412 763 70 84 16 0 0
2 0 207348 15756 78800 175424 0 0 0 0 874 25 89 11 0 0
1 0 207348 16368 78800 175596 0 0 0 0 940 24 86 14 0 0
1 0 207348 16600 78800 175604 0 0 0 0 929 27 95 3 0 2
3 0 207348 16976 78548 175876 0 0 0 2508 969 35 93 7 0 0
4 0 207348 16216 78548 175704 0 0 0 0 874 36 93 6 0 1
4 0 207348 16424 78548 175776 0 0 0 0 850 26 77 23 0 0
2 0 207348 17496 78556 175840 0 0 0 0 736 23 83 17 0 0
0 0 207348 17680 78556 175868 0 0 0 0 861 21 91 8 0 1
根据观察值,我们可以得到以下结论:
1,有大量的中断(in) 和较少的上下文切换(cs).这意味着一个单一的进程在产生对硬件设备的请求.
2,进一步显示某单个应用,user time(us) 经常在85%或者更多.考虑到较少的上下文切换,这个应用应该还在处理器中被处理.
3,运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.
3.3 案例学习:超负荷调度
在这个例子中,内核调度中的上下文切换处于饱和
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 1 207740 98476 81344 180972 0 0 2496 0 900 2883 4 12 57 27
0 1 207740 96448 83304 180984 0 0 1968 328 810 2559 8 9 83 0
0 1 207740 94404 85348 180984 0 0 2044 0 829 2879 9 6 78 7
0 1 207740 92576 87176 180984 0 0 1828 0 689 2088 3 9 78 10
2 0 207740 91300 88452 180984 0 0 1276 0 565 2182 7 6 83 4
3 1 207740 90124 89628 180984 0 0 1176 0 551 2219 2 7 91 0
4 2 207740 89240 90512 180984 0 0 880 520 443 907 22 10 67 0
5 3 207740 88056 91680 180984 0 0 1168 0 628 1248 12 11 77 0
4 2 207740 86852 92880 180984 0 0 1200 0 654 1505 6 7 87 0
6 1 207740 85736 93996 180984 0 0 1116 0 526 1512 5 10 85 0
0 1 207740 84844 94888 180984 0 0 892 0 438 1556 6 4 90 0
根据观察值,我们可以得到以下结论:
1,上下文切换数目高于中断数目,说明kernel中相当数量的时间都开销在上下文切换线程.
2,大量的上下文切换将导致CPU 利用率分类不均衡.很明显实际上等待io 请求的百分比(wa)非常高,以及user time百分比非常低(us).
3,因为CPU 都阻塞在IO请求上,所以运行队列里也有相当数目的可运行状态线程在等待执行.

4.总结：

vmstat是个动态的分析工具，利用它主要可以知道

1 cpu瓶颈  ：通过process的r,如果r大于cpu个数（队列出现等待）并且cpu idle过小（30%，那么说明cpu瓶颈

2 内存瓶颈：

2.1 看free很小了

2.2 每隔1秒观察一次，运行10次后，看swpd 的使用有无变话，如果迅速加大说明有可能磁盘不足

2.3 swap交换页面si,so频繁使用

总结：如果swpd迅速变大，si,so频繁使用，那么内存不足。

3 IO瓶颈

1 cpu wa（ waitio)超过20%

2 bi,bo（块设备从ram 读入写磁盘） 读出写入量很大，超过2000

那么出现IO瓶颈

top指令详解

在使用top命令的时候会看到这么一行：

里面的各个值分别是什么意思呢？

今天被问到这个问题，发现答的不是很清楚。果然啊，天天用最多的top命令都还没摸透。。。惭愧。。。于是就查了些资料：

官方解释

Cpu(s)表示的是cpu信息。各个值的意思是：

us: user cpu time (or) % CPU time spent in user space

sy: system cpu time (or) % CPU time spent in kernel space

ni: user nice cpu time (or) % CPU time spent on low priority processes

id: idle cpu time (or) % CPU time spent idle

wa: io wait cpu time (or) % CPU time spent in wait (on disk)

hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts

si: software irq (or) % CPU time spent servicing/handling software interrupts

st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine

 

翻译一下：

us：用户态使用的cpu时间比

sy：系统态使用的cpu时间比

ni：用做nice加权的进程分配的用户态cpu时间比

id：空闲的cpu时间比

wa：cpu等待磁盘写入完成时间

hi：硬中断消耗时间

si：软中断消耗时间

st：虚拟机偷取时间

 

好了，如果说列出上面的条条框框说我懂了，那真是自欺欺人了。下面是我自己的理解

首先这个百分比是怎么算出来的呢？

比如一秒内有100个cpu时间片，这个cpu时间片就是cpu工作的最小单位。那么这100个cpu时间片在不同的区域和目的进行操作使用，就代表这个区域所占用的cpu时间比。也就是这里得出的cpu时间百分比。

比如下面一个程序：

将文件从磁盘的src位置拷贝到磁盘的dst位置。文件会从src先读取进入到内核空间，然后再读取到用户空间，然后拷贝数据到用户空间的buf上，再通过用户空间，内核空间，数据才到磁盘的dst上。

 

所以从上面这个程序来看，cpu消耗在kernel space的时候就是sy（系统态使用的cpu百分比），cpu消耗在user space的时候就是us（用户态使用的cpu百分比）。

好了，下面说说hi和si

如果程序都没什么问题，那么是没有hi和si的，但是实际上有个硬中断和软中断的概念。比如硬中断，cpu在执行程序的时候，突然外设硬件（比如硬盘出现问题了）机器需要立刻通知cpu进行现场保存工作。这个时候会cpu会出现上下文切换。就是cpu会有一部分时间会被硬中断占用了，这个时间就是hi。相类似，si是软中断的cpu占用时间，软中断是由软件的指令方式触发的。

相关软中断和硬中断的概念可以参考：

http://blog.csdn.net/pxz_002/article/details/7327668

下面是ni

ni是nice的意思，nice是什么呢，每个linux进程都有个优先级，优先级高的进程有优先执行的权利，这个叫做pri。进程除了优先级外，还有个优先级的修正值。即比如你原先的优先级是20，然后修正值为-2，那么你最后的进程优先级为18。这个修正值就叫做进程的nice值。

 

那么nice是一个进程的优先级修正值，为什么会占用cpu时间呢？

ni是指用做nice加权的进程使用的用户态cpu时间比，我的理解就是一个进程的所谓修正值就意味着多分配一些cpu时间给这个进程的用户态，这个中间所多分配的cpu时间就是我们这里的ni。（这个理解没啥把握，如果有错误麻烦帮忙指出下）

下面是wa

wa指的是CPU等待磁盘写入完成的时间，就是说前提是要进行IO操作，在进行IO操作的时候，CPU等待时间。比如上面那个程序，最后一步，从系统空间到dst硬盘空间的时候，如果程序是阻塞的，那么这个时候cpu就要等待数据写入磁盘才能完成写操作了。所以这个时候cpu等待的时间就是wa。

所以如果一台机器看到wa特别高，那么一般说明是磁盘IO出现问题，可以使用iostat等命令继续进行详细分析。

下面是st

st的名字很生动，偷取。。。是专门对虚拟机来说的，一台物理是可以虚拟化出几台虚拟机的。在其中一台虚拟机上用top查看发现st不为0，就说明本来有这么多个cpu时间是安排给我这个虚拟机的，但是由于某种虚拟技术，把这个cpu时间分配给了其他的虚拟机了。这就叫做偷取。

id

剩下的id就是除了上面那么多cpu处理上下文以外的cpu时间片。当然在这些时间片上，cpu是空闲的。

top的所有这些cpu时间应该是相加为100%的。