Linux性能工具介绍

浏览数：21 / 时间：2015年06月20日

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 = 1000 ms/ (Tseek + Troatation)，忽略数据传输时间。假设磁盘平均物理寻道时间为3ms, 磁盘转速为7200,10K,15K rpm，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`; do ps -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