标签：des style blog http color java os 使用 io
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
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中研究
标签：des style blog http color java os 使用 io
原文地址：http://www.cnblogs.com/trhimily/p/3934508.html
