Linux系统故障排除

话说软件项目的一般流程是：设计、编码、调优、上线。

调优过程中常常遇到系统性能不够的时候。可是话说回来性能不好也正常，假设随便写点代码性能就牛X的一塌糊涂，可能也就不须要那么多的所谓的Best Prticace的经验总结了。

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

首先我们知道server的主要资源包含：

  • 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分钟的平均负载描写叙述了相对时间内负载的平均值。从以上样例中，能够看出server过去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故障排除-Linuxserver运维最佳实践》 - Kyle Rankin著
posted @ 2017-07-15 20:15  lytwajue  阅读(475)  评论(0)  编辑  收藏  举报