Linux 性能快速分析

        当你登录了一台存在性能问题的Linux服务器之后：你应该首先检查什么呢？

        通过运行下面的10条命令，在1分钟之内，你就能对系统资源使用和正在运行的进程有一个高级的认识。首先检查容易解释原因的错误和饱和度指标，然后检查资源利用率。饱和度指的是负载超过了资源的处理能力，可以通过请求队列的长度或者由于等待所消耗的时间来进行分析。

        uptime

        dmesg | tail

        vmstat 1

        mpstat -P ALL 1

        pidstat 1

        iostat -xz 1

        free -m

        sar -n DEV 1

        sar -n TCP,ETCP 1

        top

        这其中的一些命令依赖于sysstat软件包。这些命令所暴露的指标有助于你使用USE方法（一种定位性能瓶颈的方法论）对性能进行评估。这涉及对所有资源（CPU、内存和磁盘等）的利用率、饱和度和错误指标进行检查。

1、uptime

        通过这种方式，你可以快速查看平均负载，它反映了要求运行的任务数（进程数）。在Linux系统中，这些数字包括了要求在CPU上运行的进程和被不可中断的I/O（通常是磁盘I/O）所阻塞的进程。这些信息让我们对资源负载（或需求）有了一个高级的认识，但是只适合一个快速的查看，要进行详细的分析我们还需要借助其它工具。

        这3个数字表示系统在最近1分钟、5分钟和15分钟内的平均负载，让我们了解了，随着时间的推移负载是如何变化的。例如，如果你被要求检查一台出现问题的服务器，1分钟的数值比15分钟的数值低很多，那么你可能已经错过了这个问题。

        在上面这个例子中，最近1分钟的平均负载是30，最近15分钟的平均负载是19，这表明负载在增加。这些数字代表了很多事情：也许是CPU需求，我们将通过vmstat或mpstat来进行确认。

2、dmesg | tail

         这条命令可以展示最近的10条系统消息，如果存在的话。我们可以在这里查看是否存在引起性能问题的错误。上面的示例中包括了oom-killer和TCP 丢掉请求的信息。

        千万不要忽略这一步！dmesg是非常有必要检查的。

3、vmstat 1

         vmstat作为一款常见工具，可以提供虚拟内存状态的概要信息。它在每一行都打印出了关键服务器统计信息。

        vmstat命令后的参数1，表示每秒打印一次统计信息。需要注意的是，第一行输出信息中的一些列表示的是自系统启动后的平均值，而不是自上一秒。现在我们先跳过第一行，从第二行数据开始分析。

        需要检查的列：

        r：正在和等待在CPU上运行的进程数。与平均负载相比，它能更好的判断CPU的饱和度，因为它不包含I/O。需要解释一点：当”r”列的值大于CPU核心数时，就表示CPU已经饱和了。

        free：空余内存，单位是kbytes。如果这里显示了很多数字，就表示你的系统还有足够多的空余内存。

        si，so：换入和换出的内存量。如果这两个值不为0，就表示内存不足了。

        us，sy，id，wa，st：这些指标是对CPU时间的分解，代表的是所有CPU的平均值。它们分别代表的是用户时间，系统时间（内核），空闲时间，I/O等待时间，和被偷走的时间（其它虚拟机所消耗的时间）。

        通过对CPU时间的分解，我们可以确认CPU是否处于繁忙状态（用户时间+系统时间）。等待I/O的持续程度代表了磁盘的瓶颈；这时候CPU是空闲的，因为任务都被阻塞了（等待磁盘I/O）。你可以把等待I/O看作是另一种形式的CPU空闲，同时解释了空闲的原因。

        对于I/O处理来说，系统时间是必须的。如果平均系统时间值较高，大于20%，也许内核此时正低效的处理I/O。

        在上面的例子中，CPU时间几乎完全被用户级，或者说是应用级所占用。CPU的平均利用率超过了90%。这算不上是一个问题；通过”r”列来检查饱和度。

4、mpstat -P ALL 1

         这个命令打印了每个CPU核心的时间片分解，由此我们可以分析每个CPU的负载是否均衡。如果只有一个CPU核心的负载很重，可能表示了一个单线程的应用正运行在该核心上。

5、pidstat 1

         pidstat 有点类似top命令的每个进程统计，但是可以打印一个滚动的统计信息，而不是每次统计都会清空屏幕。当我们处于观察者模式时，或者需要将这些信息复制到报告中时，这种方式是很实用的。

        上面的例子中，有两个java进程在严重的消耗CPU。%CPU这一列代表的是所有的CPU；1591%表示那个java进程正在消耗几乎16个CPU。

6、iostat -xz 1

         这是一个很棒的工具，可以帮助我们理解块设备，包括负载和由此产生的性能问题。注意该工具生成的第一个报告是自系统启动之后的统计信息。

        r/s, w/s, rkB/s, wkB/s：这些指的是设备每秒的读次数，写次数，读Kbytes数，写Kbyte数。这些可以作为负载特性。性能问题可能就是由于其中一个过度的负载导致的。

        await：I/O等待的平均时间（毫秒）。这是应用程序必须要忍受的时间，它包括了队列时间和响应时间。如果超过了预期的平均时间，可能就表明了设备已饱和或者设备发生了故障。

        avgqu-sz：设备的平均请求数。值大于1，表示该设备出现了饱和（尽管很多设备可以并行处理请求，尤其是对应多个后端磁盘的虚拟设备）。

        %util：设备利用率。这表明了该设备每秒钟有多少比例的时间正在处理工作。对于不同的设备，通常值高于60%会导致很糟糕的性能表现（在await中可以看到），值接近100%表明设备已经饱和了。

        如果存储设备是一个对应很多后端磁盘的逻辑磁盘的话，那么100%的利用率也许仅仅意味着该设备正在用100%的时间去处理一些I/O，后端的磁盘也许远没有达到饱和，也许还能继续处理更多的工作。

        有一点需要注意，糟糕的磁盘I/O性能并不一定会导致应用出现问题。我们可以通过很多技术来实现异步I/O，所以应用程序不会直接被阻塞和延迟（例如读缓存，写缓存）。

7、free -m

         buffers：代表buffer cache，用于块设备I/O

        cached：代表page cache，用于文件系统

        我们只需要检查这两项不是接近于0即可，接近于0会导致更高的磁盘I/O，和更糟糕的性能。上面的例子看起来很好，每一项都有很多Mbytes的空间。

        “-/+ buffers/cache”更清晰的展示了已使用和空余的内存。Linux使用空余内存作为缓存，但是当应用需要内存时可以快速的释放掉。所以按照这种思路来思考的话，缓存的内存也应该被包含在空余内存列中，这一行就是这样显示的。

        如果Linux正在使用ZFS，我们可能会出现困惑，因ZFS有它自己的文件系统缓存，而这不能通过free -m列来显示。可能会出现一种现象，系统显示空余内存很少，但是实际上ZFS缓存却很充裕。

8、sar -n DEV 1

         这个工具可以用来检查网络接口的吞吐量：每秒接收的kB数和每秒发送的kB数，这可以作为对负载的衡量，同时需要检查是否达到了某些限制。在上面的例子中，eth0接收速度达到了22Mbytes/s，也就是176Mbits/s（低于1Gbits/sb）。

9、sar -n TCP,ETCP 1

        这里展示了一些关键的TCP指标统计，包括：

        active/s：本地每秒初始化的TCP连接数（通过connect()建立的连接）

        passive/s：远程每秒初始化的TCP连接数（通过accept()建立的连接）

        retrains/s：每秒重新建立的TCP连接数

        主动和被动连接数可以用来粗略的衡量服务器负载。我们可以把主动连接理解为从本地向外部建立的连接，把被动连接理解为从外部向本地建立的连接，这有点不严谨，因为还有一种情况是localhost到localhost方向的连接。

        重新建立连接的现象表示网络或服务器出现了问题；也许是由于不可靠的网络（例如公网）导致的，也许是由于服务器负载过高并丢包所导致的。上面的例子显示每秒只有一个新的TCP连接。

10、top

         top的缺点是，我们很难观察这些指标随着时间发生了什么变化，vmstat和pidstat通过滚动的输出结果，很好的解决了这个问题。而对于一些间歇性的问题出现的时候，如果你没有及时的暂停输出（Ctrl-S暂停，Ctrl-Q继续），你可能会错过这个问题，因为屏幕会被清空。