l  Linux性能工具介绍

p  CPU高

p  磁盘I/O

p  网络

p  内存

p  应用程序跟踪

l  操作系统与应用程序的关系比喻为“唇亡齿寒”一点不为过

l  应用程序的性能问题/功能问题，除了使用在线调试、日志以外，操作系统提供了丰富的工具让你透视应用程序，问题定位分析的效率更高

l  介绍Linux工具使用资料很多，这里不介绍工具使用，而是告诉工具背后数字的含义，以及我们平时对工具输出常见的误解

CPU高-uptime

l  uptime和top命令都会显示最近1分钟、5分钟、15分钟的负载

l  Linux中所有的进程放在一个称之为run queue的队列中，上面的输出表示的是:已经在运行(获取到CPU)+等待运行的进程数，例如上面的0.62表示的是最近1分钟运行的队列个数是: 0.62*60 = 37

l  只有1个cpu的情况，但是当多核时,就类似于多车道，假设为n核，最大可接受的负载为n.0.在Linux中查看/proc/cpuinfo获得CPU的个数

l  这个数值一般超过CPU核的2倍表示有严重的性能问题，例如假设某8核的电脑，此数值持续的超过16,说明等待严重，但是如果只是瞬间，可以不用过于关注

l  uptime和top的只能看到最近1、5、15分钟，

CPU高-vmstat

l  如果想看到实时的队列长度，查看vmstat命令的输出第一列: r

l  vmstat命令的输出的信息量较大，只描述与CPU相关的指标

l  r: 同前面的uptime命令中提到run queue的长度是一样的，如果这个数量大于CPU核个数的2倍表示有严重的性能瓶颈

l  b:处于uninterruptible sleep状态的进程个数.进程进入睡眠状态有2种方式，interruptible sleep:可接受信号或者被唤醒，uninterruptible sleep表示不接受信号，只能被对对应事件唤醒,一般进入这种状态表示的是等待I/O(磁盘I/O或者网络I/O,需要分别判断).同样如果处于b持续多，可能意味I/O有瓶颈

l  us/sy/id/wa:

l  us:在非核心态花费的时间占比，这个如果高一般意味着应用程序的算法实现有性能问题

l  sy:在核心态占用的时间比，一般指的是系统调用花费的时间

l  id:空闲时间

l  wa:在等待IO上花费的时间，注意这个指标有一些难以理解，在下一页会详细讲解

l  wa:iowait近100%并不表示系统就是不健康的,同样道理iowait为0%的并不表示就是一个健康的系统.因为我们知道CPU的性能每隔12或者18个月就会提升一倍，而磁盘的性能受限于物理特性其IOPS( IO Operations Per Second) ，而iowait = (CPU处于空闲且等待IO完成时间)/(CPU运行时间+ (CPU处于空闲且等待IO完成时间)

l  假设某款CPU,因为CPU性能差一些，最后算出来的%iowait是33%.

       CPU  time = 40 ms
IO time = 20 ms
Total transaction time = CPU + IO = 40 + 20 = 60 ms
%iowait = IO time/total time = 20/60 = 33%

l  这时换了另一款CPU,此CPU性能有大幅提升，CPU计算的时间大幅减少:

  CPU time = 40 ms/ 4 = 10 ms
IO time = 20 ms
Total transaction time = CPU + IO = 10 + 20 = 30 ms
%iowait = 20/30 = 66%

l  从上面可以看出，CPU性能提升了，但是%iowait却提升了2倍

l  iowait本身只是I/O可能有问题的指示,需要进一步结合其它数据分析

l  不同的硬件间的iowait比较没有太大的意义

CPU高-查看哪个进程CPU高

l  ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpu中第6列是CPU占用从小到大的列出

l  找到进程以后，根据进程的类型获取堆栈进行分析:

p  如果是Java程序，如果IBM JDK,使用kill -3生成java core,如果是SUN JDK,使用JDK自带的程序jstack生成

p  如果是C++或者C语言编译的程序，使用gstack<pid>生成线程的堆栈

l  分析堆栈时，如果CPU高，需要多次获取堆栈进行对比，排除掉处于wait、sleep等状态的线程，如果某线程一直存在且不是处于等待状态则有可能是罪魁祸首

磁盘I/O高-iostat

l  在前一页提到vmstat中%iowait来准备判断是否有IO瓶颈并不是什么的准确,更好的指标是IOPS,即iostat的tps列的输出:

l  iops属于比较专业的术语,

l  根据不同的磁盘类型计算出最大IOPS,IOPS =1000ms/(Tseek+Trotation),这样算出来: 因此，理论上可以计算出磁盘的最大IOPS，即IOPS = 1000ms/ (Tseek + Troatation)，忽略数据传输时间。假设磁盘平均物理寻道时间为3ms, 磁盘转速为7200,10K,15Krpm，Trotation一般为磁盘旋转一周的1/2计算，则磁盘IOPS理论最大值分别为，

IOPS = 1000 / (3 + 60000/7200/2) = 140

IOPS = 1000 / (3 + 60000/10000/2) = 167

IOPS = 1000 / (3 + 60000/15000/2) = 200

磁盘I/O高

l  大部分情况下，我们都没有达到磁盘的I/O瓶颈，更多的时候是我们的应用程序需要优化，前面的iowait或者vmstat 的b列只能看到I/O的具体情况，如要看到哪一个进程I/O高，有2种方式:

p  第三方工具iotop, http://guichaz.free.fr/iotop/

p  或者比较简单的: for x in `seq 1 1 10`; dops -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5;done

       这个命令的意思是检查状态处于D(即前面uninterruptable state的进程，一般是在等待I/O)

网络问题

l  traceroute 用于检测到达目的地的路由是否正确,有时一些路由配置不正确会导致消息走了不该走的路

l  ping:这个就不用说了..

l  sar -n DEV -I ALL <interval> <count> 用于检测每个网卡的流量.对于大流量的应用，比如门户网站，完全是有可能把流量撑满的.不要以为100M的网站实际真的能达到100M bits,受限于网卡或者网线的实际能力，并不能达到真正的100M bits

l  tcpdump 抓包必备,注意如果本机到本机，网卡必须为lo(loop back)

l  netstat 查看socket的状态.例如:经常出现TIME_WAIT状态。网络连接无法建立等状态也可以通过netstat结合tcpdump来进行分析，例如:DNS的/etc/resolve.conf配置不正确，导致GetHostByName从域名获取IP时，会查询多次

内存占用高

l  page cache(cache&buffer) 为了尽可能的缓存磁盘上的数据到内存提升性能使用，page cache包括2部分:文件的数据块和文件的元数据(supberblock、inodes、bitmaps),像free、top等命令分别把前面显示为cached,后者显示为buffer,这2个和就是page cache

free并不是Linux真正的空闲的内存，要把buffer和cache加上

内存占用高

l  当内存不足时，slab、buffer、cache会首先进行瘦身，不断的shrink，并开始使用swap,这时使用vmstat会看到大量的换入和换出(si和so)

l  如果vmstat的si和so数据很大，说明内存已经不够用了,使用ps aux查看哪一个进程的内存占用多,在ps aux的输出要看RSS(常驻内存)列

l  对于Java之类的进程,不要使用Linux操作系统的命令查看，而是使用JVM自己的工具，例如:jmap,因为这些工具是自行管理内存的

其它

l  strace 跟踪进程的系统调用,例如:某个程序在运行的过程中突然hang住了，可以用strace跟踪调用在哪一个系统调用挂住

l  gdb 调试应用

l  /proc文件系统，可以透视进程的几乎所有状态,比如定位socket挂死等，有兴趣的可以在单板的/usr/src/linux/Documentation/filesystems/proc.txt中研究

Linux性能工具介绍