forlinux系统监控诊断工具1.问：最近一直在做日志的实时同步，请问各位大侠有什么办法吗？在上线之前，我做了一次单机在线日志压力测试。消息队列、客户端和本地机器都很好。但是没想到第二次log之后，问题来了：集群top中的某台机器看到了巨大的负载，集群中机器的硬件配置是一样的，部署的软件也是一样的，但是只有这个负载有问题，初步猜测可能是硬件问题。同时，我们还需要找出负载异常的元凶，然后从软件和硬件层面寻找解决方案。2、排查：从上图可以看出loadaverage偏高，%wa偏高??，%us偏低：从上图我们可以大致推断是IO遇到了瓶颈。接下来，我们就可以使用相关的IO诊断工具了。验证和检查。PS：如果不知道top的用法，可以参考我去年写的一篇博文：Linux系统监控诊断工具top。?使用free和vmstat查看是否是内存瓶颈?使用iostat和dmesg查看是否是磁盘I/O瓶颈?使用netstat查看是否是网络带宽瓶颈2.1vmstatvmstat命令的含义是显示虚拟内存的状态（“ViryualMemoryStatics”），但它可以报告系统整体的进程、内存、I/O等运行状态。其相关字段说明如下：Procs（进程）?r：运行队列中的进程数，这个值也可以决定是否增加CPU。（长期大于1）?b：等待IO的进程数，即处于非中断休眠状态的进程数，表示正在执行并等待CPU资源的任务数。当这个值超过CPU数量时，就会出现CPU瓶颈。系统性能。?free：空闲物理内存大小。?buff：用作缓冲区的内存大小。?cache：用于缓存的内存大小。如果缓存值很大，说明缓存中的文件很多。如果可以缓存经常访问的文件，磁盘读取IObi就会很小。Swap?si：每秒从交换区写入内存的大小，从磁盘传输到内存。?so：每秒写入交换区的内存大小，从内存传输到磁盘。注意：当内存足够时，这两个值都是0。如果这两个值长期大于0，会影响系统性能，会消耗磁盘IO和CPU资源。有些朋友看到空闲内存（free）很少或者接近于0的时候，就认为是内存不够用了。不能只看这个，还要结合si等。如果free很少，但是si和so也很少（大部分时候为0），那么不用担心，此时不会影响系统性能。IO（当前Linux版本的块大小为1kb）?bi：每秒读取的块数?bo：每秒写入的块数注意：读写随机磁盘时，两个值越大（如果超过1024k），可见CPU等待IO的值会更大。系统(system)?in：每秒中断次数，包括时钟中断。?cs：每秒上下文切换的次数。注意：以上2个值越大，内核消耗的CPU时间就越多。CPU（以百分比表示）?us：用户进程执行时间百分比（usertime）当us的值比较高时，表示用户进程消耗CPU时间较多，但如果使用率长期超过50%，则我们应该考虑优化程序算法或者提速。?sy：内核系统进程执行时间百分比（systemtime）当sy的值很高时，表示系统内核消耗了大量的CPU资源。这不是良性的表现，我们应该检查原因。?wa：IO等待时间百分比当wa的值很高时，说明IO等待比较严重，可能是磁盘上大量的随机访问，或者是磁盘的瓶颈（块操作）。?id:空闲时间百分比从vmstat可以看出大部分CPU时间都浪费在等待IO上，这可能是大量的磁盘随机访问或磁盘带宽造成的。bi和bo也超过了1024k，应该是遇到了IO瓶颈。2.2iostat接下来使用比较专业的磁盘IO诊断工具查看相关统计数据。其相关字段说明如下：rrqm/s：每秒进行merge的读操作数。即delta(rmerge)/swrqm/s：每秒merge的写操作数。即delta(wmerge)/sr/s：每秒完成的读I/O设备数。即delta(rio)/sw/s：每秒完成的写I/O设备数。即delta(wio)/srsec/s：每秒读扇区数。即delta(rsect)/swsec/s：每秒写入的扇区数。即delta(wsect)/srkB/s：每秒读取的K字节数。它是rsect/s的一半，因为每个扇区的大小为512字节。（需要计算）wkB/s：每秒写入K字节。它是wsec/s的一半。（需要计算）avgrq-sz：每次设备I/O操作的平均数据大小（扇区）。delta(rsect+wsect)/delta(rio+wio)avgqu-sz：平均I/O队列长度。即delta(aveq)/s/1000（因为aveq的单位是毫秒）。await：每个设备I/O操作的平均等待时间（以毫秒为单位）。即delta(ruse+wuse)/delta(rio+wio)svctm：每次设备I/O操作的平均服务时间（毫秒）。即delta(use)/delta(rio+wio)%util：每秒有多少百分比用于I/O操作，或者说每秒有多少次I/O队列不为空。即delta(use)/s/1000（因为use的单位是毫秒），我们可以看到两个硬盘中sdb的利用率都达到了100%，IO瓶颈严重。下一步是找出哪个进程正在运行这个硬盘读写数据。2.3iotop根据iotop的结果，我们很快定位到了flume进程的问题，导致大量IO等待。但是正如我开头所说的，集群中机器的配置是一样的，rsync部署的程序也和以前一模一样。会不会是硬盘坏了？这个还得请运维同学检查一下。最后得出的结论是：sdb是双盘raid1，使用的raid卡是“LSILogic/SymbiosLogicSAS1068E”，没有cache。近400IOPS的压力已经达到了硬件极限。其他机器用的raid卡是“LSILogic/SymbiosLogicMegaRAIDSAS1078”，有256MB缓存，不过硬件瓶颈还没到。解决方案是更换能够提供更大IOPS的机器。但是前面说过，我们从硬件和软件入手的目的是看能否分别找到成本最小的解决方案：知道硬件的原因，我们可以尝试将读写操作移到另一个磁盘，然后看一下效果：3.***字：另辟蹊径其实除了使用上面提到的专业工具来定位这个问题，我们还可以直接使用进程状态来查找相关进程。我们知道进程有如下几种状态：PROCESSSTATECODESDuninterruptiblesleep（通常是IO）Rrunningorrunnable（onrunqueue）Sinterruptiblesleep（waitingforaneventtocomplete）Tstopped，要么是通过作业控制信号，要么是因为它被跟踪。Wpaging(notvalidsincethe2.6.xxkernel)Xdead(shouldneverbeseen)Zdefunct("zombie")process,terminatedbutnotreapedbyitsparent.其中状态D一般是由于waitIO导致所谓的“非中断睡眠”。我们可以从这点出发，一步步定位问题：forxin`seq10`;dops-eostate,pid,cmd|grep"^D";echo"----";sleep5;doneD248[jbd2/dm-0-8]D16528bonnie++-n0-u0-r239-s478-f-b-d/tmp----D22[kdmflush]D16528bonnie++-n0-u0-r239-s478-f-b-d/tmp----#or:whiletrue;dodate;psauxf|awk'{if($8=="D")print$0;}';sleep1;doneTueAug2320:03:54CLT2011root3020.00.000?DMay222:58\_[kdmflush]root3210.00.000?DMay224:11\_[jbd2/dm-0-8]TueAug2320:03:55CLT2011TueAug2320:03:56CLT2011cat/proc/16528/iorchar:48752567wchar:54996:57896sys：67138读字节：49020928写字节：549961728cancelled_write_bytes:0lsof-p16528COMMANDPIDUSERFDTYPEDEVICESIZE/OFFNODENAMEbonnie++16528rootcwdDIR252,04096130597/tmp
