性能分析的目标是改善用户体验、降低运行成本。性能分析的方法论可以指导你进行这些选择,告诉你从哪里开始,一步步分析,最后在哪里结束。
本文选自《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
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.
这个命令可以显示过去 10 条系统日志。注意在这里寻找可能导致性能问题的错误。这个例子显示了内存不足引发 OOM 和 TCP 的丢弃请求的记录。TCP 的相关日志甚至指引了我们下一步的分析方向 :查看 SNMP 计数器值。
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
至此,你已经使用前面列举的工具看到了很多指标。不过再多做一步会更有益 :我们以 top 命令作为结束,对相关结果进行二次确认,并能够浏览系统和进程的摘要信息。运气好的话,这个 60 秒分析过程会帮助你找到一些性能问题的线索。在此基础上,可以使用专门的 BPF 工具开展进一步分析。
BPF之巅
▊《BPF之巅:洞悉Linux系统和应用性能》
【美】Brendan Gregg 著
孙宇聪 吕宏利 刘晓舟 译
● Gregg大师新作,《性能之巅》再续新篇
● 性能优化的万用金典,150+分析调试工具深度剖析
本书作为全面介绍 BPF 技术的图书,从 BPF 技术的起源到未来发展方向都有涵盖,不仅全面介绍了 BPF 的编程模型,还完整介绍了两个主要的 BPF 前端编程框架 — BCC 和 bpftrace,更给出了一系列实现范例,生动展示了 BPF技术的实际能力和未来发展前景。
▼扫码立即获取详情▼
如果喜欢本文
欢迎 在看丨留言丨分享至朋友圈 三连
热文推荐
▼点击阅读原文,获取本书详情~
本文分享自 博文视点Broadview 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!