Linux系统故障排除

话说软件项目的一般流程是：设计、编码、调优、上线。调优过程中经常遇到系统性能不够的时候，但是话说回来性能不好也正常，如果随便写点代码性能就牛X的一塌糊涂，可能也就不需要那么多的所谓的Best Prticace的经验总结了。

最近看到一本书《DevOps故障排除》,书很薄，里面的内容可能在其他书中都有讲解，但是他总结的很好，可能对系统的发生故障后的排除流程做了一般总结，对于我来说，可能在调优阶段分析系统瓶颈的时候有很大帮助，特此记下学习笔记。

首先我们知道服务器的主要资源包括：

• CPU
• RAM
• 磁盘IO
• 网络

系统出了问题怎么办呢，我想重启可能会解决，但是这就可能失去了让你成为高手的机会。如果可以的话，登录系统上，应该有一些工具可以排查出到底是谁在搞飞机（为什么是应该，因为过去我也不了解，但是马上就会知道了）

1 系统负载

通常第一条命令是uptime：

03:11:10 up 38 days,  6:26,  1 user,  load average: 2.03, 20.17, 15.09

• load average后面3个数字0.08、0.04、0.00分别代表了1分钟、5分钟、15分钟内机器的平均负载。一个系统的平均负载等于处于运行或者不可打扰状态的进程平均数。可运行的进程要么正在使用CPU，要么正在等待使用CPU；不可打扰状态的进程都在等待IO响应。
• 平均负载为1的单CPU系统意味着该CPU处于恒定负载；如果单CPU系统平均负载为4，说明这个系统处于可承受能力的4倍，所有3/4的进程都在等待资源。当然，负载状态为1的单CPU系统与负载状态为4的四核CPU系统使用资源的量一样。
• 1分钟、5分钟、15分钟的平均负载描述了相对时间内负载的平均值。从以上例子中，可以看出服务器过去1分钟负载为2，但是在过去的5分钟却飙升到了20，而前15分钟负载平均为15。这说明，机器在过去15分钟处于高负载状态，并且5分钟前系统的负载又有增长，但是目前已经减弱。

再看一个：

03:11:10 up 38 days,  6:26,  1 user,  load average: 17.29, 0.12, 0.01

• 以上例子中，5分钟、15分钟的平均负载很低，但1分钟内平均负载很高，所以可以知道负载的飙升发生在最近。所以可以使用top命令来观察负载是持续上升还是下降。

平均负载多少算高？

这取决于产生高负载的原因。明确负载是CPU密集型（等待CPU资源的进程）、RAM密集型（尤其是频繁使用的RAM被已入了交换区）还是IO密集型（抢夺磁盘或网络IO资源的进程）非常重要。

• 通常CPU密集型的系统会比IO密集型的系统影响度更高，这样在这些系统上运行故障排查工具会有良好的响应时间（就是还是比较快吧）
• 对于IO负载较高的IO密集型系统，通常登录这些系统就需要花费一段时间，因为磁盘IO可能已经饱和了。
• 用尽RAM的系统通常与IO密集型的系统表现相同，因为一旦系统开始使用磁盘上的交换存储，它就会消耗磁盘资源，导致进程逐渐变慢直至停止。

2 使用top命令排查负载问题

要排查高负载的问题，第一个工具是top。

top命令的输出

• 第一行输出与uptime的输出一致，可以看出这台机器的负载并不大。

top - 04:35:45 up 38 days,  7:50,  2 users,  load average: 0.00, 0.00, 0.00

• Cpu(s)提供了运行情况的信息

Cpu(s):  2.0%us,  0.2%sy,  0.0%ni, 97.6%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st

• us：运行非优雅的用户进程所占CPU时间的百分比
• sy：运行内核和内核进程所占CPU时间百分比
• ni：优雅CPU时间
• id：代表了的空闲时间比。如果系统运行很慢，但是这个指标特别高，那么负载的原因不是高CPU负载。
• wa：等待执行IO操作所占的百分比，当解决运行缓慢的系统问题的时候，这是一个非常有价值的指标，如果这个值很低，那么就能轻松排除磁盘或者网络IO问题。

3 解决高CPU负载问题

症状：%us CPU高、IO %wa低。需要确定系统中哪一个进程占用了如此大量的CPU资源。

一般情况下，大部分高CPU负载的情况都是由CPU被一个、多个进程消耗殆尽。

4 解决RAM不足的问题

top输出中以下两行提供了RAM的使用情况，如

Mem:   3849548k total,  3819152k used,    30396k free,    15144k buffers
Swap:  2097144k total,  1604548k used,   492596k free,    75248k cached

• 第一行是有多少物理内存可用、占用了多少、空闲多少、缓存了多少内存。
• 第二行是交换存储以及Linux文件缓存使用了多少RAM。

可以看出，系统内存真用尽了，因为系统只剩下30396KB空闲内存，文件缓存占用75248KB内存（本来这部分内存也是可以给其他进程用的，但是这里实在太小了）。而Swap已经用了1.6G了，因此系统的内存显然是不够用了。

这下内存真的存在问题了，那么如果确定哪些进程消耗了RAM。top默认按照CPU的使用率排序进程，所以需要将其改为按照RAM使用率来排序，保持top的打开状态，按下M键，这就会让所有进程按照RAM使用率排序。

• 注意到%MEM一列，按照内存的使用百分比的顺序列出所有进程，这样我们便可找到占用内存最高的进程，然后就可以针对目标进程进行分析，为什么使用了这么多的内存。（哈哈，看到了么，这可是我们线上的系统的某台机器的进程列表，还好目前业务量很小，否则不堪设想，并且我已经修了这个Memory Leak的问题，很有成就感）

5 解决高IO wait等待时间问题

当看到IO %wa很高的时候，首先需要检查机器时候使用大量的交换空间，因为磁盘操作速度远远低于RAM，所以当系统内存好近，开始使用交换空间的时候，系统的性能会收到严重影响。所以第一步要看内存是否耗尽，如果是，则先解决这个问题。如果还有大量RAM，则需要明确那个进程占用了大部分操作。

很难看明白哪个进程占用了大量的IO资源，高级命令登场：
* iostat（sysstat包中有这个命令）

    Linux 2.6.32-431.el6.x86_64 (nj-figo-cui)   08/09/2015  _x86_64_    (4 CPU)

    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               0.25    0.00    0.11    0.01    0.00   99.63

    Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
    sda               0.30        12.25        16.48    9632378   12956192
    dm-0              2.24        12.24        16.45    9622250   12933488
    dm-1              0.00         0.00         0.00       2640          0

• avg-cpu: CPU信息
• tps：这个值列出了设备每秒的传输量。“传输”是想设备发送IO请求的另一种表达方式。
• Blk_read/s：表示每秒从设备读取的数据量。
• Blk_write/s: 表示每秒向设备写入的数据量。
• Blk_read: 表示从设备读取的数据总量。

• Blk_write: 表示向设备写入的数据总量。

  当系统处于高IO负载状态的时候，可以观察哪个分区的负载最高，这样就缩小了范围。若是知道了某个分区IO高，那么接下来就可以看那些个进程的数据存储在这个分区（相信大数据量的进程毕竟是少数，这样一般就能找到目标进程。）

  • iotop
    这个命令与top命令类似，但是这个命令的输出是根据各个进程的IO情况的排序，以下是个例子，这里不再详述。

Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    4 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    5 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]
    7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]

6 问题发生后的高负载处理

很有可能机器负载很高时，登录不上去了。因此可以通过工具记录全天的性能数据，那么若是有人抱怨中午的时候系统慢的时候，就可以上去查看日志，看看是什么原因引起的这个问题。

有两个工具可以用，atop和sysstat。

• atop

  • 安装完atop包之后，atop命令自动启动(/usr/bin/atop -a -w /var/log/atop/atop_20150809 600)。这个命令的意思是，只记录活动的进程、采样周期600秒、并将结果写入/var/log/atop/atop_20150809文件。
  • atop将统计结果写入/var/log/atop/目录中，我们可以通过atop查看历史信息。执行atop -r /var/log/atop/atop_20150731，如下图，这里不再详述。
    

• sysstat（不是很熟悉，有空熟悉熟悉）

  • sysstat命令安装完成之后，每10分钟收集一次系统状态经存储于/var/log/sysstat或者/var/log/sa文件中，另外，每天还会分割文件。这些都是/etc/cron.d/sysstat脚本执行的，该脚本内容为：

# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1
# 0 * * * * root /usr/lib64/sa/sa1 600 6 &
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

第一条命令会每10分钟执行一次；第二条命令会在每天23:53执行一次（生成的进程accounting的每日统计）。

• 收集的内容如下，具体使用方法请查看（sar -h）
  
  • 负载平均值
  • CPU负载
  • RAM
  • 磁盘IO
  • 网络IO等

ok，说了这么多，其实就是为了在系统性能遇到瓶颈的时候，帮助一些开发者定位一下系统瓶颈的来源，具体经验还得靠个人积累，如果对你有帮助，我就很有成就感！

参考：

• 《DevOps故障排除-Linux服务器运维最佳实践》 - Kyle Rankin著