60 秒 Linux 检查清单，快速初步定位你的性能问题
性能分析的目标是改善用户体验、降低运行成本。性能分析的方法论可以指导你进行这些选择，告诉你从哪里开始，一步步分析，最后在哪里结束。
本文选自《BPF之巅：洞悉Linux系统和应用性能》一书，将向你介绍一个 Linux 下的 60 秒分析的检查清单，你在做日常性能分析工作时可以首先使用它~它能直接帮助你快速定位性能问题，或者至少提供进一步使用哪些 BPF 工具进行分析的线索。60秒清单
这个清单适用于任何性能问题的分析工作，也反映了笔者在实际工作中，当登录到一台表现不佳的 Linux 系统中后，在最初 60 秒内通常会进行的操作。
要运行的工具是 ：
1. uptime
2. dmesg | tail
3. vmstat 1
4. mpstat -P ALL 1
5. pidstat 1
6. iostat -xz 1
7. free -m
8. sar -n DEV 1
9. sar -n TCP,ETCP 1
10. top
下面的我们会依次介绍每个工具。这些命令有可能会帮助你快速直接定位出性能问题。即便不能的话，这些工具也能暴露问题根源的线索，以便指引你后续使用 BPF 工具进一步定位真正的问题。1.uptime
2 03:16:59 up 17 days, 4:18, 1 user, load average: 2.74, 2.54, 2.58
这个工具可以快速检查平均负载，也就是有多少个任务（进程）需要执行。在Linux 系统中，这些数字包含了想要在 CPU 上运行的进程，同时也包含了阻塞在不可中断 I/O（通常是磁盘 I/O）上的进程。这给出了一个高层次视角的资源负载（或者说资源需求），在此之后可以通过其他工具进行进一步检查。
这 3 个数字分别是指数衰减的 1 分钟 /5 分钟 /15 分钟滑动窗口累积值。通过这 3 个值可以大致了解负载随时间变化的情况。上面的例子显示负载最近有小幅的提升。
负载的平均值值得在排障过程中被首先进行检查，以确认性能问题是否还存在。在一个容错的环境中，一台存在性能问题的服务器，在你登录到机器上时，也许已经自动从服务列表中下线了。一个较高的 15 分钟负载与一个较低的 1 分钟负载同时出现，可能意味着已经错过了问题发生的现场。2. dmesg | tail
1$ dmesg | tail
2[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
3[...]
4[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
5[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB,
6file-rss:0kB
7[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP
8counters.
3. vmstat 1
这个虚拟内存统计工具最早源于 BSD，同时还展示了一些其他的系统指标。当执行时带着命令行参数 1 时，会隔 1 秒打印一次摘要信息 ；注意，第 1 行输出的数字是自系统启动后的统计值（内存相关的计数器除外）。
需要检查的列包括如下几个。
r ：CPU 上正在执行的和等待执行的进程数量。相比平均负载来说，这是一个更好的排查 CPU 饱和度的指标，因为它不包含 I/O。可以这样解释 ：一个比 CPU数量多的 r 值代表 CPU 资源处于饱和状态。
free ：空闲内存，单位是KB。如果数字位数一眼数不过来，那么内存应该是够用的。使用 free -m 命令，可以更好地解释空闲内存。
si 和 so ：页换入和页换出。如果这些值不是零，那么意味着系统内存紧张。这个值只有在配置开启了交换分区后才会起作用。
us、sy、id、wa 和 st ：这些都是 CPU 运行时间的进一步细分，是对所有的CPU 取平均之后的结果。它们分别代表用户态时间、系统态时间（内核）、空闲、等待 I/O，以及被窃取时间（stolen time，指的是虚拟化环境下，被其他客户机所挤占的时间 ；或者是 Xen 环境下客户机自身隔离的驱动域运行时间）。
上面的例子显示了 CPU 时间主要花在用户态上。这指引我们下一步将主要针对用户态代码进行剖析。4. mpstat -P ALL 1
这个命令将每个 CPU 分解到各个状态下的时间打印出来。上面的输出暴露了一个问题 ：CPU 0 的用户态的占比高达 100%，这是单个线程遇到瓶颈的特征。
对于比较高的 %iowait 时间也要注意，可以使用磁盘 I/O 工具进一步分析 ；如果出现较高的 %sys 值，可以使用系统调用（syscall）跟踪和内核跟踪，以及 CPU 剖析等手段进一步分析。5. pidstat 1
pidstat(1) 命令按每个进程展示 CPU 的使用情况。top(1) 命令虽然也很流行，但是pidstat(1) 默认支持滚动打印输出，这样可以采集到不同时间段的数据变化。这个输出显示了一个 Java 进程每秒使用的 CPU 资源在变化 ；这个百分比是对全部 CPU 相加的和 ，因此 500% 相当于 5 个 100% 运行的 CPU。
注意，最近pidstat(1)有一个修改，即将其百分比的上限定在100%。这在多线程的情况下，可能会导致错误的输出。尽管这个改动已经被撤回了，但还是提醒你注意一下是否使用了有错误改动的pidstat(1)版本。6. iostat -xz 1
这个工具显示了存储设备的 I/O 指标。上面的每个磁盘设备输出行由于过长进行了换行，阅读起来稍显不便。
要检查的列包括如下几个。
r/s、w/s、rkB/s 和 wkB/s：这些是每秒向设备发送的读、写次数，以及读、写字节数。可以用这些指标对业务负载画像。某些性能问题仅仅是因为超过了能够承受的最大负载导致的。
await ：I/O 的平均响应时间，以毫秒为单位。这是应用需要承受的时间，它同时包含了 I/O 队列时间和服务时间。超过预期的平均响应时间，可看作设备已饱和或者设备层面有问题的表征。
avgqu-sz ：设备请求队列的平均长度。比 1 大的值有可能是发生饱和的表征（不过对有些设备，尤其是对基于多块磁盘的虚拟设备来说，通常以并行方式处理请求）。
%util ：设备使用率。这是设备繁忙程度的百分比，显示了每秒设备开展实际工作的时间占比。不过它展示的并不是容量规划意义下的使用率，因为设备可以并行处理请求。大于 60% 的值通常会导致性能变差（可以通过 await 字段确认），不过这也取决于具体设备。接近 100% 的值通常代表了设备达到饱和状态。
注意，这有时会引起困惑，比如当iostat(1)报告说某个设备已经达到100%的使用率后，还能够接受更高的负载。它只是报告某个设备在一段时间内100%繁忙，并没有说设备的使用率达到100%了：此时也许仍然可以接受更高的负载。在一个卷后面有多个磁盘设备支撑的情况下由于可以并行处理请求，iostat(1)中的%util这个指标就更加具有迷惑性。
上面的输出显示了向 md0 虚拟设备的写入负载约为 300MB/s，看起来 md0 的背后是两块 nvme 设备。7. free -m
这个输出显示了用兆字节（MB）作为单位的可用内存。检查可用内存（available）是否接近 0 ；这个值显示了在系统中还有多少实际剩余内存可用，包括缓冲区和页缓存区。将一些内存用于缓存可以提升文件系统的性能。
注意，free(1) 命令的输出格式最近也有修改。
过去是把 buff 和 cache字段分开列出，并且没有 available 字段，用户需要时要自行计算available的值。笔者更喜欢新版的输出。如果想分开展示 buff 和 cache，可以使用命令行参数-w开启宽屏模式。
8. sar -n DEV 1
将不同的指标进行组合，sar(1) 工具有不同的运行模式。在这个例子中，笔者使用它来查看网络设备指标。通过接口吞吐量信息 rxkB/s 和 txkB/s 来检查是否有指标达到了上限。
9. sar -n TCP,ETCP 1
现在我们使用 sar(1) 工具来查看 TCP 指标和 TCP 错误信息。相关的字段包括如下几个。
active/s ：每秒本地发起的 TCP 连接的数量（通过调用 connect() 创建）。
passive/s ：每秒远端发起的 TCP 连接的数量（通过调用 accept() 创建）。
retrans/s ：每秒 TCP 重传的数量。
主动和被动连接计数对于业务负载画像很有用。重传则是网络或者远端主机有问题的征兆。10. top
BPF之巅
▊《BPF之巅：洞悉Linux系统和应用性能》【美】Brendan Gregg 著
孙宇聪 吕宏利 刘晓舟 译
● Gregg大师新作，《性能之巅》再续新篇
● 性能优化的万用金典，150+分析调试工具深度剖析
本书作为全面介绍 BPF 技术的图书，从 BPF 技术的起源到未来发展方向都有涵盖，不仅全面介绍了 BPF 的编程模型，还完整介绍了两个主要的 BPF 前端编程框架 — BCC 和 bpftrace，更给出了一系列实现范例，生动展示了 BPF技术的实际能力和未来发展前景。
▼扫码立即获取详情▼如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连
热文推荐