DevOp经验谈：服务故障排查的第一…

    近来接手了一个比较大型的项目，由于系统内部服务数量较为众多，且没有物理机或者虚拟机的隔离措施。导致系统出现故障的概率大大增加，带给维护很大的压力。最近这段时间也是久病成医，现在总结服务故障排查的一些经验，在此文和大家分享下。

    我有些时候会对技术人员提出这样的问题：如果服务出故障了，比如http服务无法返回或者返回很慢，应该要怎么排查？   大多数的人的回答是到服务器上看日志。其实这个答案并不是太好。如果系统资源 （四大金刚：CPU、内存、磁盘、网络）被耗尽或者有问题，从日志上不容易看出问题的根源，往往看到的只是问题的表现。比如日志上显示某个操作很慢，有可能是CPU忙，有可能是内存不够用，也可能是磁盘IO被某个服务占满。直接看日志容易被问题的表现迷惑，没办法快速定位到问题的根源。我有次让某个开发去查看某台服务器上的服务故障。然后他惊呼连连：一会儿说MySQL有问题，一会儿说mongoDB有问题，一会儿说服务自己有问题（看stack都堵塞在写日志）。结果呢？ 其实只是磁盘IO被备份程序用满罢了。

      所以故障排查一定要先检查直接影响性能的四大要素： CPU、内存、磁盘、网络。先排除资源的问题，再查看服务内部的状态。这也是服务故障排查第一分钟要做的事情，需要用到的命令有：top、free、vmstat(iostat)。

      一、头30秒，使用top了解服务器的负载情况，并且查看一下是否有程序CPU异常。

     top命令细节的我就不讲了，如果不了解细节可以在网上自行搜索下，我说说我的使用经验吧：

      1、top显示的内存不要看。经常有缺少经验的同事向我报告：服务器内存都用完了。但其实不是，top显示用掉的内存有不少是操作系统用来作为buffer和cache的，这部分内存随时可以分配给进程使用。看内存要用free命令才对。

      2、要了解系统平时的负载情况，包括忙时的和闲时的。否则很难判断现在系统是否过载。

      3、要了解程序平时的CPU情况，同样也是包括忙时的和闲时的。比如有的服务平时CPU负载就是在400%+的，查看的时候在500%+也并不奇怪。但如果平时长期在50%的服务突然间飙涨到500%，那就很可能有问题了。

      4、如果发现CPU负载异常地低。往往预示着其他系统资源到达瓶颈，导致服务快不起来，从而CPU负载比平常来的低。这也是一个线索。

      二、用10秒扫一下内存情况，用free命令。

      要关注下图中用红圈圈起来的地方，不要被第一行迷惑。

      如果当前free很小，大量使用Swap，则表示内存不足。如果当前free足够，大量使用Swap，表示历史上出现过内存不足，在救火时无需理会，如果有空的时候可以看看是否有程序使用了大量的内存，这可能是由于内存泄露引发的。

      三、用20 秒查看一下磁盘IO的情况，可使用vmstat和iostat命令。      

     此时我们主要是想了解磁盘的IO情况，所以主要关注bi/bo，一个块默认是4KB，如果BI为100，则每秒从磁盘读取400KB的数据，如果BI为100，则每秒写入400KB的数据到磁盘。这两个数值多少是OK的呢？ It depends。我们现在使用的大多数服务器，这两个数值的峰值能到20000，但如果长期超过14000，就会导致服务变慢，经常无法及时响应了。以上数值是特定服务器上的经验之谈，没有普适性，不要奉为定律。比如使用固态硬盘，BI/BO的峰值肯定会有很大提升。

      以我的经验，CPU、内存、磁盘IO中最容易到达瓶颈的是磁盘IO。系统资源耗尽十之八九落在磁盘IO上。

      最后：通过以上三个步骤，我们可以初步判断出问题到底是系统资源耗尽导致的还是服务自身导致的。如果是前者则要进一步找到耗尽系统资源的罪魁祸首，比如CPU飙涨的进程（top就能看出来），占用巨大内存的进程（一般top也能看出来，res特别高的，如果不行就用 ps）、疯狂读写磁盘IO的进程（如果linux版本比较新可以用iotop，不然用dstat），然后该杀杀，该关关。

     细心的同学可能会发现，说好的四大金刚呢？说好的网络呢？ 是这样的，大多数网络问题是互联互通的问题，在服务器上是不好测试的，需要从不同网络的服务器traceroute这台服务器来进行测试。如果是某个服务把网络IO耗尽导致的问题，压根不用测试，ssh连上去就会发现操作十分地卡顿，这时候一般会尝试ping一下服务器，会发现丢包很严重。这一块我们有专职的人员负责，我报告他们即可。他们平时有统计带宽情况（如果要实时查看我会用iptraf），一般解决办法是对某些IP进行限速（使用TC工具限速）。

--------------------------------------------------------------------------

      补充：以上介绍地是如何确定单台服务器是否到达性能瓶颈。如果服务器不止一台的话，那情况就会更为复杂。有种比较典型的服务器架构是一台对外的服务器（提供如web等服务）、一台数据库服务器（提供如MySQL等的数据存储服务）。如果这种架构的服务出现问题，我会如此处理：

      1、首先登陆对外服务器，执行三板斧（top、free、vmstat）。如果有负载偏高，则具体查看。如果负载偏低的话，有一个可能是因为数据服务的 调用 速度太慢，导致对外的服务都在等待数据所以负载很低。这种情况下我会先确认数据服务器是否有状况。

      2、首先ping数据服务器，看看时延和丢包。如果在内网环境下，一般时延在1ms以下，如果时延在几十ms甚至更多，或者存在丢包，说明两台服务器之间的连接有问题。可以查看下网卡状态（ ethtool ），重启对应网卡（ ifconfig ethX up | down ) 。如果还不行就要通知机房处理了。

      3、如果ping没发现问题，则登录数据服务器， 执行三板斧（top、free、vmstat）。如果负载高的异常，具体查看。如果负载正常或者偏低，则一般不是数据服务导致的问题，可以掉过头去更深入地研究对外服务的异常原因。