Linux系统故障排除

本文发布时间: 2019-Mar-22
话说软件项目的一般流程是:设计、编码、调优、上线。调优过程中经常遇到系统性能不够的时候,但是话说回来性能不好也正常,如果随便写点代码性能就牛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.09load 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.00Cpu(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%stus:运行非优雅的用户进程所占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 buffersSwap: 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 0avg-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:5353 23 * * * root /usr/lib64/sa/sa2 -A第一条命令会每10分钟执行一次;第二条命令会在每天23:53执行一次(生成的进程accounting的每日统计)。收集的内容如下,具体使用方法请查看(sar -h)负载平均值 CPU负载 RAM 磁盘IO 网络IO等 ok,说了这么多,其实就是为了在系统性能遇到瓶颈的时候,帮助一些开发者定位一下系统瓶颈的来源,具体经验还得靠个人积累,如果对你有帮助,我就很有成就感!


(以上内容不代表本站观点。)
---------------------------------


2019-Mar-25 01:00am
栏目列表