系统性能分析主要包括，系统的性能分析

简介：本文以系统为中心, 结合日常工作和用例, 由浅入深地介绍了性能分析的一些方法和体会, 希望对想了解系统性能分析的同学有所帮助。

作者 | 勿非
来源 | 阿里技术公众号

本文以系统为中心, 结合日常工作和用例, 由浅入深地介绍了性能分析的一些方法和体会, 希望对想了解系统性能分析的同学有所帮助。

一 入门篇

1 资源角度

USE

产品跑在系统的各种资源上面, 从系统资源的角度入门性能分析是个不错的选择, 我们以业界知名大牛Brendan Gregg的USE方法开始, USE特点就是简单有效适合入门, 用Brendan的话描述USE的效果:

I find it solves about 80% of server issues with 5% of the effort.

USE从系统资源的角度, 包括但不限于CPU, 内存, 磁盘, 网络等, 关注以下3个方面:

• Utilization (U): as a percent over a time interval. eg, "one disk is running at 90% utilization". 大多数情况可以合理推测利用率高可能会影响性能
• Saturation (S): as a queue length. eg, "the CPUs have an average run queue length of four". 资源竞争的激烈程度
• Errors (E). scalar counts. eg, "this network interface has had fifty late collisions". Errors相对直观

CPU

对于CPU, 主要关注以下指标:

• Utilization. CPU的利用率
• Saturation. 可以是load average, runqueue length, sched latency等

CPU利用率用top看下:

top-17:13:49up83days,23:10,1user,load average:433.52,422.54,438.70Tasks:2765total,23running,1621sleeping,0stopped,34zombie%Cpu(s):23.4us,9.5sy,0.0ni,65.5id,0.7wa,0.0hi,1.0si,0.0st

CPU利用率拆分成了更细粒度的几部分:

• us, sys, ni - 对应un-niced user, kernel, niced user的CPU利用率
• id, wa - 对应到idle, io wait的比例, io wait本质上也是一种idle, 区别在于对应cpu上有等待io的任务
• hi, si - 对应hardirq, softirq的比例
• st - 因为超卖等原因, hypervisor从该vm偷走的时间 (todo: docker)

继续看load average, 3个数值分别对应到系统1/5/15分钟内的系统平均load, load是个比较模糊的概念, 可以简单认为是对资源有需求的任务数, 包括on cpu, runnable的任务, 也包括等待IO及任意D状态的任务. load使用采样的方式, 每隔5秒采样一样, 越近的采样权重越大, 这样从1/5/15的趋势可以看出系统压力的变化。

load average:433.52,422.54,438.70

在这台128个CPU的机器上, loadavg看起来有些偏高, 但是具体影响目前不得而知, 性能低是相对具体目标而言的, load高只是现象, 它可能相关也可能无关, 但至少是值得注意的。

再看下dstat关于任务状态的统计:

• run - 对应到/proc/stat里面的procs_running, 也就是runnable任务数
• blk - 对应到/proc/stat里面的procs_blocked, 阻塞在I/O的任务数

实际上和loadavg没有本质区别, 只是load模糊了runnable和D状态, 同时load使用1/5/15分钟的力度, 而dstat可以使用更细粒度, 如果只看某一时间点用load, 如果要观察长时间的变化使用dstat (/proc/stat)。

#dstat -tp----system-------procs---time|runblknew07-0317:56:50|2041.020207-0317:56:51|212023807-0317:56:52|3461.026607-0317:56:53|2795.026207-0317:56:54|4357.017707-0317:56:55|4423.025107-0317:56:56|7928.041907-0317:56:57|5041615207-0317:56:58|5473.015607-0317:56:59|6062.021207-0317:57:00|7700186

内存

这里主要关注内存容量方面, 不关注访存的性能。

• Utilization. 内存利用率
• Saturation. 这里主要考察内存回收算法的效率

简单的内存利用率用free命令:

• total - MemTotal + SwapTotal, 一般来说MemTotal会略小于真实的物理内存
• free - 未使用的内存. Linux倾向于缓存更多页面以提高性能, 所以不能简通过free来判断内存是否不足
• buff/cache - 系统缓存, 一般不需要严格区分buffer和cache
• available - 估计的可用物理内存大小
• used - 等于total - free - buffers - cache
• Swap - 该机器上未配置

#free -gtotalusedfreesharedbuff/cacheavailableMem:50319372301301Swap:000

更详细的信息可以直接去读/proc/meminfo:

#cat /proc/meminfoMemTotal:527624224kBMemFree:8177852kBMemAvailable:316023388kBBuffers:23920716kBCached:275403332kBSwapCached:0kBActive:59079772kBInactive:431064908kBActive(anon):1593580kBInactive(anon):191649352kBActive(file):57486192kBInactive(file):239415556kBUnevictable:249700kBMlocked:249700kBSwapTotal:0kBSwapFree:0kB[...]

再来看下内存回收相关的信息, sar的数据主要从/proc/vmstat采集, 主要关注:

• pgscank/pgscand - 分别对应kswapd/direct内存回收时扫描的page数
• pgsteal - 回收的page数
• %vmeff - pgsteal/(pgscank+pgscand)

要理解这些数据的具体含义, 需要对内存管理算法有一定了解, 比如这里的pgscan/pgsteal只是针对inactive list而言的, 在内存回收的时候可能还需要先把页面从active list搬到inactive list等. 如果这里有异常, 我们可以先把这当成入口, 再慢慢深入, 具体到这里的%vmeff, 较好情况就是每个扫描的page都能回收, 也就是vmeff越高越好。

#sar -B 111:00:16AMpgscank/spgscand/spgsteal/s%vmeff11:00:17AM0.000.003591.000.0011:00:18AM0.000.0010313.000.0011:00:19AM0.000.008452.000.00

I/O

存储I/O的USE模型:

• Utilization. 存储设备的利用率, 单位时间内设备在处理I/O请求的时间
• Saturation. 队列长度

我们一般关注这些部分:

• %util - 利用率. 注意即使达到100%的util, 也不代表设备没有性能余量了, 特别地现在的SSD盘内部都支持并发. 打个比方, 一家旅馆有10间房, 每天只要有1个房间入住, util就是100%。
• svctm - 新版iostat已经删掉
• await/r_await/w_await - I/O延迟, 包括排队时间
• avgrq-sz - 平均request size, 请求处理时间和大小有一定关系, 不一定线性
• argqu-sz - 评估queue size, 可以用来判断是否有积压
• rMB/s, wMB/s, r/s, w/s - 基本语义

点击链接查看原文，关注公众号【阿里技术】获取更多福利！
https://mp.weixin.qq.com/s/7ct-mvSIaT3o4-tsMaKRWA

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。