快捷搜索：  汽车  科技
当前位置： 爱玩科技 > 科技 > 正文

分析系统性能的基本方法（系统性能分析从入门到进阶）

威哥 666

分析系统性能的基本方法（系统性能分析从入门到进阶）对于CPU 主要关注以下指标:CPU产品跑在系统的各种资源上面 从系统资源的角度入门性能分析是个不错的选择 我们以业界知名大牛Brendan Gregg的USE方法开始 USE特点就是简单有效适合入门 用Brendan的话描述USE的效果:I find it solves about 80% of server issues with 5% of the effort.USE从系统资源的角度 包括但不限于Cpu 内存 磁盘 网络等 关注以下3个方面:

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

分析系统性能的基本方法（系统性能分析从入门到进阶）(1)

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

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

一 入门篇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:49 up 83 days 23:10 1 user load average: 433.52 422.54 438.70 Tasks: 2765 total 23 running 1621 sleeping 0 stopped 34 zombie %Cpu(s): 23.4 us 9.5 sy 0.0 ni 65.5 id 0.7 wa 0.0 hi 1.0 si 0.0 st

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 |run blk new 07-03 17:56:50|204 1.0 202 07-03 17:56:51|212 0 238 07-03 17:56:52|346 1.0 266 07-03 17:56:53|279 5.0 262 07-03 17:56:54|435 7.0 177 07-03 17:56:55|442 3.0 251 07-03 17:56:56|792 8.0 419 07-03 17:56:57|504 16 152 07-03 17:56:58|547 3.0 156 07-03 17:56:59|606 2.0 212 07-03 17:57:00|770 0 186

内存

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

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

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

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

#free -g total used free shared buff/cache available Mem: 503 193 7 2 301 301 Swap: 0 0 0

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

#cat /proc/meminfo MemTotal: 527624224 kB MemFree: 8177852 kB MemAvailable: 316023388 kB Buffers: 23920716 kB Cached: 275403332 kB SwapCached: 0 kB Active: 59079772 kB Inactive: 431064908 kB Active(anon): 1593580 kB Inactive(anon): 191649352 kB Active(file): 57486192 kB Inactive(file): 239415556 kB Unevictable: 249700 kB Mlocked: 249700 kB SwapTotal: 0 kB SwapFree: 0 kB [...]

再来看下内存回收相关的信息 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 1 11:00:16 AM pgscank/s pgscand/s pgsteal/s %vmeff 11:00:17 AM 0.00 0.00 3591.00 0.00 11:00:18 AM 0.00 0.00 10313.00 0.00 11:00:19 AM 0.00 0.00 8452.00 0.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

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

网站首页

返回栏目

猜您喜欢：

相关文章