linux问题排查方式，linux故障定位参考

1. 背景

有时候会遇到一些疑难杂症，并且监控插件并不能一眼立马发现问题的根源。这时候就需要登录服务器进一步深入分析问题的根源。那么分析问题需要有一定的技术经验积累，并且有些问题涉及到的领域非常广，才能定位到问题。所以，分析问题和踩坑是非常锻炼一个人的成长和提升自我能力。如果我们有一套好的分析工具，那将是事半功倍，能够帮助大家快速定位问题，节省大家很多时间做更深入的事情。

2. 说明

本篇文章主要介绍各种问题定位的工具以及会结合案例分析问题。

3. 分析问题的方法论

套用5W2H方法，可以提出性能分析的几个问题

  • What-现象是什么样的
  • When-什么时候发生
  • Why-为什么会发生
  • Where-哪个地方发生的问题
  • How much-耗费了多少资源
  • How to do-怎么解决问题

4. cpu

4.1 说明

针对应用程序，我们通常关注的是内核CPU调度器功能和性能。

线程的状态分析主要是分析线程的时间用在什么地方，而线程状态的分类一般分为：

a. on-CPU：执行中，执行中的时间通常又分为用户态时间user和系统态时间sys。
b. off-CPU：等待下一轮上CPU，或者等待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。

如果大量时间花在CPU上，对CPU的剖析能够迅速解释原因；如果系统时间大量处于off-cpu状态，定位问题就会费时很多。但是仍然需要清楚一些概念：

  • 处理器
  • 核
  • 硬件线程
  • CPU内存缓存
  • 时钟频率
  • 每指令周期数CPI和每周期指令数IPC
  • CPU指令
  • 使用率
  • 用户时间／内核时间
  • 调度器
  • 运行队列
  • 抢占
  • 多进程
  • 多线程
  • 字长

4.2 分析工具

工具描述
uptime 平均负载
vmstat 包括系统范围的cpu平均负载
mpstat 查看所有cpu核信息
top 监控每个进程cpu用量
sar -u 查看cpu信息
pidstat 每个进程cpu用量分解
perf cpu剖析和跟踪，性能计数分析

说明:

  • uptime,vmstat,mpstat,top,pidstat只能查询到cpu及负载的的使用情况。
  • perf可以跟着到进程内部具体函数耗时情况，并且可以指定内核函数进行统计，指哪打哪。

4.3 使用方式

//查看系统cpu使用情况
top

//查看所有cpu核信息
mpstat -P ALL 1

//查看cpu使用情况以及平均负载
vmstat 1

//进程cpu的统计信息
pidstat -u 1 -p pid

//跟踪进程内部函数级cpu使用情况
perf top -p pid -e cpu-clock

5. 内存

5.1 说明

内存是为提高效率而生，实际分析问题的时候，内存出现问题可能不只是影响性能，而是影响服务或者引起其他问题。同样对于内存有些概念需要清楚：

  • 主存
  • 虚拟内存
  • 常驻内存
  • 地址空间
  • OOM
  • 页缓存
  • 缺页
  • 换页
  • 交换空间
  • 交换
  • 用户分配器libc、glibc、libmalloc和mtmalloc
  • LINUX内核级SLUB分配器

5.2 分析工具

工具描述
free 缓存容量统计信息
vmstat 虚拟内存统计信息
top 监视每个进程的内存使用情况
pidstat 显示活动进程的内存使用统计
pmap 查看进程的内存映像信息
sar -r 查看内存
dtrace 动态跟踪
valgrind 分析程序性能及程序中的内存泄露错误

说明：

  • free,vmstat,top,pidstat,pmap只能统计内存信息以及进程的内存使用情况。
  • valgrind可以分析内存泄漏问题。
  • dtrace动态跟踪。需要对内核函数有很深入的了解，通过D语言编写脚本完成跟踪。

5.3 使用方式

//查看系统内存使用情况
free -m

//虚拟内存统计信息
vmstat 1

//查看系统内存情况
top

//1s采集周期，获取内存的统计信息
pidstat -p pid -r 1

//查看进程的内存映像信息
pmap -d pid

//检测程序内存问题
valgrind --tool=memcheck --leak-check=full --log-file=./log.txt  ./程序名

6. 磁盘IO

6.1 说明

磁盘通常是计算机最慢的子系统，也是最容易出现性能瓶颈的地方，因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作，比如转轴、寻轨等。访问硬盘和访问内存之间的速度差别是以数量级来计算的，就像1天和1分钟的差别一样。要监测 IO 性能，有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。

在理解磁盘IO之前，同样我们需要理解一些概念，例如：

  • 文件系统
  • VFS
  • 文件系统缓存
  • 页缓存page cache
  • 缓冲区高速缓存buffer cache
  • 目录缓存
  • inode
  • inode缓存
  • noop调用策略

6.2 分析工具

工具描述
iostat 磁盘详细统计信息
iotop 按进程查看磁盘IO的使用情况
pidstat 按进程查看磁盘IO的使用情况
perf 动态跟踪工具

6.3 使用方式

//查看系统io信息
iotop

//统计io详细信息
iostat -d -x -k 1 10

//查看进程级io的信息
pidstat -d 1 -p  pid

//查看系统IO的请求，比如可以在发现系统IO异常时，可以使用该命令进行调查，就能指定到底是什么原因导致的IO异常
perf record -e block:block_rq_issue -ag
^C
perf report

7. 网络

7.1 说明

网络的监测是所有 Linux 子系统里面最复杂的，有太多的因素在里面，比如：延迟、阻塞、冲突、丢包等，更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为 Linux 网络子系统的问题还是别的设备的问题，增加了监测和判断的复杂度。现在我们使用的所有网卡都称为自适应网卡，意思是说能根据网络上的不同网络设备导致的不同网络速度和工作模式进行自动调整。

7.2 分析工具

工具描述
ping 主要透过 ICMP 封包 来进行整个网络的状况报告
traceroute 用来检测发出数据包的主机到目标主机之间所经过的网关数量的工具
netstat 用于显示与IP、TCP、UDP和ICMP协议相关的统计数据，一般用于检验本机各端口的网络连接情况
ss 可以用来获取socket统计信息，而且比netstat更快速更高效
host 可以用来查出某个主机名的 IP,跟nslookup作用一样
tcpdump 是以包为单位进行输出的，阅读起来不是很方便
tcpflow 是面向tcp流的, 每个tcp传输会保存成一个文件,很方便的查看
sar -n DEV 网卡流量情况
sar -n SOCK 查询网络以及tcp，udp状态信息

7.3 使用方式

//显示网络统计信息
netstat -s

//显示当前UDP连接状况
netstat -nu

//显示UDP端口号的使用情况
netstat -apu

//统计机器中网络连接各个状态个数
netstat -a | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

//显示TCP连接
ss -t -a

//显示sockets摘要信息
ss -s

//显示所有udp sockets
ss -u -a

//tcp,etcp状态
sar -n TCP,ETCP 1

//查看网络IO
sar -n DEV 1

//抓包以包为单位进行输出
tcpdump -i eth1 host 192.168.1.1 and port 80 

//抓包以流为单位显示数据内容
tcpflow -cp host 192.168.1.1

8. 系统负载

8.1 说明

Load 就是对计算机干活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）简单的说是进程队列的长度。Load Average 就是一段时间（1分钟、5分钟、15分钟）内平均Load。

8.2 分析工具

工具描述
top 查看系统负载情况
uptime 查看系统负载情况
strace 统计跟踪内核态信息
vmstat 查看负载情况
dmesg 查看内核日志信息

8.3使用方式

//查看负载情况
uptime

top

vmstat

//统计系统调用耗时情况
strace -c -p pid

//跟踪指定的系统操作例如epoll_wait
strace -T -e epoll_wait -p pid

//查看内核日志信息
dmesg

 

10. 案例分析

10.1 接入层nginx集群异常现象

通过监控插件发现在2017.09.25 19点nginx集群请求流量出现大量的499，5xx状态码。并且发现机器cpu使用率升高，目前一直持续中。

10.2 分析nginx相关指标

a) ****分析nginx请求流量：

 
image.png

结论：

通过上图发现流量并没有突增，反而下降了，跟请求流量突增没关系。

b) ****分析nginx响应时间

 
image.png

结论：

通过上图发现nginx的响应时间有增加可能跟nginx自身有关系或者跟后端upstream响应时间有关系。

c) ****分析nginx upstream响应时间

 
image.png

结论：

通过上图发现nginx upstream 响应时间有增加，目前猜测可能后端upstream响应时间拖住nginx，导致nginx出现请求流量异常。

10.3 分析系统cpu情况

a) ****通过top观察系统指标

top
 
image.png

结论：

发现nginx worker cpu比较高

b) ****分析nginx进程内部cpu情况

perf top -p pid
 
image.png

结论：

发现主要开销在free,malloc,json解析上面

10.5 案例总结

**a) **分析请求流量异常，得出nginx upstream后端机器响应时间拉长

**b) **分析nginx进程cpu高，得出nginx内部模块代码有耗时的json解析以及内存分配回收操作

10.5.1 深入分析

根据以上两点问题分析的结论，我们进一步深入分析。

后端upstream响应拉长，最多可能影响nginx的处理能力。但是不可能会影响nginx内部模块占用过多的cpu操作。并且当时占用cpu高的模块，是在请求的时候才会走的逻辑。不太可能是upstram后端拖住nginx，从而触发这个cpu的耗时操作。

10.5.2 解决方式

遇到这种问题，我们优先解决已知的，并且非常明确的问题。那就是cpu高的问题。解决方式先降级关闭占用cpu过高的模块，然后进行观察。经过降级关闭该模块cpu降下来了，并且nginx请求流量也正常了。之所以会影响upstream时间拉长，因为upstream后端的服务调用的接口可能是个环路再次走回到nginx。

11. 参考资料


转自：下列信息
作者：lihanglucien
链接：https://www.jianshu.com/p/0bbac570fa4c
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
posted @ 2023-07-05 10:21  郭大侠1  阅读(47)  评论(0)  编辑  收藏  举报