使用sar命令分析Linux卡死

卡死现象

Linux卡死时的现象无法通过网络连接到Console，ping 主机IP时通的，但是telnet常用端口比如22等是不通的。
机器重启后，查看日志发现日志在机器卡死时间节点后就断掉了，就像机器被突然拔掉了电源。
Linux系统卡死危害是非常大的，一般系统卡死后机器失去响应，无法通过正常手段对系统进行操控，如果没有安装相关的带外管理口，很有可能需要运维人员进入到机房进行手动重启才能恢复。

找到sar文件

sar是Linux每隔一段时间都会对系统收集各种资源使用的工具，每一天都会产生一个文件，存储在/var/log/sa/目录下。根据服务出问题的开始时间节点很容易找到该日期所对应的sa文件。

排查思路

对于一个计算机系统最重要的资源包括CPU、内存、IO
、网络带宽…，而与我们这篇文章主题相关的资源其实只有CPU、内存、IO。

罗列出计算机系统相关比较核心重要的资源后就可以着手分析系统死机前一段时间相关资源的使用状态了。对于一个卡死的系统而言，卡死之前一般会伴随着特定多个指标的升高，找到这些升高的指标是我们定位问题的关键所在。

CPU

对于cpu而言我们比较关心的是负载信息。通过sar的以下选项可以查看cpu负载相关的信息。
-q Queue length and load average statistics
-u [ ALL ] CPU utilization statistics
sar -u -f sa15
sar -q -f sa15

内存

内存使用率是我们比较关心的指标包括内存使用率，内存页的一些指标。通过sar命令的以下选项可以查看内存的状态。
-B Paging statistics
-r Memory utilization statistics
-R Memory statistics
-H Hugepages utilization statistics
sar -B -f sa15
sar -r -f sa15
sar -R -f sa15
sar -H -f sa15

当然此处的内存资源不仅仅是指物理内存还要包括SWAP分区，操作系统理论告诉我们当主机内存（物理页框）低于某个阈值时系统会对页进行回收，如果没有缓存页回收（缓存页是读取磁盘数据时留下的，以后再次读取相邻或者相同的磁盘数据不需要再向物理磁盘请求）就需要将进程中的页表写入swap分区将内存释放出来。当进程调度需要运行的时候可能又会用到写入swap分区的页表，此时又需要将数据从swap分区读回到内存，当然如果此时内存依然不够，又需要将其他的页表写入swap分区…
当然上面一大段的目的就是告诉我们当机器卡死之前swap分区的相关写入读取速率需要重点关注。

sar命令关于SWAP的选项如下：
-S Swap space utilization statistics
-W Swapping statistics
sar -S -f sa15
sar -W -f sa15

磁盘

磁盘作为计算机系统下层的存储部件，其特点就是存储量特别大但是速度特别慢，如果磁盘使用率比较高的话造成其他请求磁盘的进程阻塞。
查看磁盘相关的选项：

-b I/O and transfer rate statistics
-d Block device statistics
sar -b -f sa15
sar -d -f sa15

分析卡死逻辑

上文中提到，使用sar命令分析系统卡死，一般会找到多个指标在卡死前的一段时间内升高，理清楚这些指标的的关联关系也就找到了系统卡死的原因，之后结合系统自身的运行服务的特点（比如CPU密集、内存密集、IO密集等）进行系统服务方面的根因定位。

此处我们以一个实例为例，某天我们发现某台Linux服务器出现了卡死现象，在我们手动重启了服务器之后我们分析卡死的原因。首先查看cpu使用情况如下：

上图发现在客户机器卡死之前IOwait一直很高，在完成手动重启后IOwait回到正常值范围内。接下来很自然的想到IOwait值为什么会升高呢，是磁盘读写的数据量真的特别大吗?或者硬盘故障导致raid降级造成IO卡顿又或者raid卡故障？怀着这些疑问我们看一下磁盘的使用情况。

对比故障时和机器重启故障恢复之后的情况可以非常明显的看到磁盘在故障时的读写量非常大是平时的4倍上下。这样大的IO应该可以初步排除掉磁盘的故障了。那又是什么导致了这样的IO量呢？
第一种情况是系统应用使用的IO，比如本机是数据库服务器而业务量剧增。如果服务器有多个分区我们可以通过sar命令查看系统中哪个分区的IO量升高，此处需要配合服务的日志和服务写入数据的分区进行判断。

第二种情况是操作系统内存和swap分区的交换。如果确实发生了这种情况，可以结合系统运行的服务（比如Redis）是否是高内存使用量的服务占用了大量的内存导致系统内存资源严重不足。我们通过sar命令查看swap信息。

从上图可以看出机器卡死之前swap分区使用量的确非常大。那么此时是否确实发生了大量的swap分区交换呢。


上图可以明显的看到swap分区在机器卡死之前发生了大量的页交换。
至此我们通过分析sar文件可以得出结论是系统中的内存使用量飙升导致了swap分区的频繁交换，使机器陷入服务都在等待IO，推升了机器IOWAIT，进一步影响到了CPU使用率，机器卡死时系统所有的精力应该都花费在内存与swap之间的数据交换上。

MEMORY信息查看

I/O信息查看