【编者按】作者 Emil Soman,Rubyist,除此之外竟然同时也是艺术家,吉他手,Garden City RubyConf 组织者。本文是 DIY Ruby CPU Profiling 的第二部分。本文系 OneAPM 工程师编译整理。

在第一部分中我们学习了 CPU 分析的含义和进行 CPU 分析的两种方法,点此处回顾第一篇精彩内容。在这一部分我们将研究 CPU time 和 Wall time,这些部分总被用来测量执行开销。我们也会写一些实现这些测量方法的代码作为建立 CPU 分析的第一步。

Part II. CPU time 和 Wall time

Wall time

Wall time 是在一个方法被调用和返回之间的真实时间。因此,如果你想要测量一个方法执行的 「Wall clock time」,理论上可以用秒表来测量。只要在方法开始执行时打开秒表,在方法返回时按下停止。这个时间通常也被称为真实时间。

关于 Wall time 很重要的一点是,可以预见,每次试图测量同一段代码可能得到不同的结果。这是因为一系列后台进程会影响 Wall time. 当 CPU 同时运行多个进程的时候,操作系统给同时运行的进程排期并且试图为它们公平的分配 CPU 空间。这意味着 CPU 花费的总时间被分成多个片而我们的方法只占用其中的一些时间片。因此,当 Wall clock 开始计时,我们的进程可能会闲置并且为并行运行的其他进程让路。这意味着花费在其他进程的时间将增加我们的 Wall time!

CPU time

CPU time 是指 CPU 执行方法的时间。CPU time 的度量单位是用于执行方法的 CPU 时钟周期。如果我们了解 CPU 频率,它的单位是周期每秒,也可以称作赫兹,那么我们可以将其转换为时间。如果 CPU 执行某一方法花了 x 个时钟周期,这个 CPU 频率是 y 赫兹,那么 CPU 执行方法的时间为 x/y 秒。有时操作系统会为我们自动进行转换从而使我们免于进行这种计算。
CPU 时间不等同于 Wall time,其中的差别在于方法的指令类型。我们可以宽泛的将指令分为两种类型:CPU 密集型 和 I/O 密集型. 在执行 I/O 指令时,CPU 空闲下来可以转去执行其他 CPU 密集型指令。因此,如果我们的方法在 I/O 指令上花费时间,CPU 可以不把时间投入在该方法上,而是去处理其他事情,直到 I/O 操作完成。 这段时间内 Wall time 在计时而 CPU time 停止计时,落后于 Wall time.

我们来看看一个需要5分钟来执行的慢方法的情况。如果想知道这个方法花费了多长时间,你的 Wall clock 可以显示「执行该方法需要五分钟」,但 CPU 会显示「执行该方法中用时 3 分钟」。所以应该听从哪一个说法呢?究竟哪个时间能够更准确的测量执行方法的时间?

答案是:看情况。这取决于你希望测量的方法的类型。如果该方法的大部分时间用于 I/O 操作,或者该方法没有直接处理 CPU 密集型指令,由 CPU time 描述的时间开销将十分不准确。对于这些类型的方法,通过 Wall time 来测量时间更加合适。而对于其他情况,坚持通过 CPU time 来测量是很可靠的。

测量 CPU time 和 Wall time

鉴于想要写一个 CPU 分析器,我们需要一种测量 CPU time 和 Wall time 的方法。下面来看一看已经能够测量这两项的 Ruby 的 Benchmark module 中的代码。

def measure(label = "") # :yield:t0, r0 = Process.times, Process.clock_gettime(BENCHMARK_CLOCK)yieldt1, r1 = Process.times, Process.clock_gettime(BENCHMARK_CLOCK)Benchmark::Tms.new(t1.utime  - t0.utime,t1.stime  - t0.stime,t1.cutime - t0.cutime,t1.cstime - t0.cstime,r1 - r0,label)
end

由此可见,Ruby 通过两种进程类中的方法来测量时间:

  1. 通过times测量 CPU time.
  2. 通过clock_gettime来测量真实时间,也就是 Wall time.
    但是times方法返回的结果为1秒,这表示通过分析器用times只能测量仅需要几秒就能完成的 方法的 CPU time. 然而clock_gettime就有趣多了。

clock_gettime

Process::clock_gettime是早在 Ruby 2.1 版本就已经被添加的方法,它使用 POSIX clock_gettime()功能并回退到 OS 仿真来获得时间以防clock_gettime在 OS 中失效或无法实施。该功能接受clock_id及时间结果作为参数。有很多可以被选为这种计时器的clock_ids,但我们感兴趣的是:

  1. CLOCK_MONOTONIC: 这个计时器测量逃走的 Wall clock time,因为过去的任意时间点不会被系统时钟的变化影响,最适合测量 Wall time.
  2. CLOCK_PROCESS_CUPTIME_ID: 这个计时器测量每一个进程的 CPU time,意即计算进程中所有线程的时间。我们可以用它来测量 CPU time.
    让我们利用这个来写一些代码:
module DiyProf# These methods make use of `clock_gettime` method introduced in Ruby 2.1# to measure CPU time and Wall clock time.def self.cpu_timeProcess.clock_gettime(Process::CLOCK_PROCESS_CPUTIME_ID, :microsecond)enddef self.wall_timeProcess.clock_gettime(Process::CLOCK_MONOTONIC, :microsecond)end
end

可以在 benchmark 代码中使用这些方法:

puts "****CPU Bound****"
c1, w1 = DiyProf::cpu_time, DiyProf::wall_time
10000.times do |i|Math.sqrt(i)
end
c2, w2 = DiyProf::cpu_time, DiyProf::wall_time
puts "CPU time\t=\t#{c2-c1}\nWall time\t=\t#{w2-w1}"puts "\n****IO Bound****"
require 'tempfile'c1, w1 = DiyProf::cpu_time, DiyProf::wall_time
1000.times do |i|Tempfile.create('file') do |f|f.puts(i)end
end
c2, w2 = DiyProf::cpu_time, DiyProf::wall_time
puts "CPU time\t=\t#{c2-c1}\nWall time\t=\t#{w2-w1}"

运行这些代码会得出类似以下的结果:

****CPU Bound****
CPU time    =   5038
Wall time   =   5142****IO Bound****
CPU time    =   337898
Wall time   =   475864

这些清楚地展现了单个 CPU 内核的情况,在仅运行 CPU 密集型指令时 CPU time 和 Wall time 几乎相等,而运行 I/O 密集型指令时 CPU time 总是少于 Wall time.

概括

我们学习了 CPU time 和 Wall time 的含义与差异,以及什么时候用哪种。与此同时,写了一些 Ruby 代码来测量 CPU time 和 Wall time 来为我们做的 CPU 分析器测量时间。在第三部分我们将讨论 Ruby TracePoint API 并利用它做一个仪表分析器。

原文链接:http://crypt.codemancers.com/posts/2015-03-06-diy-ruby-cpu-profiling-part-i/

OneAPM for Ruby 能够深入到所有 Ruby 应用内部完成应用性能管理和监控,包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。 想技术文章,请访问 OneAPM 官方博客。

转载于:https://www.cnblogs.com/oneapm/p/4913594.html

DIY Ruby CPU 分析 Part II相关推荐

  1. DIY Ruby CPU 分析 Part III

    [编者按]作者 Emil Soman,Rubyist,除此之外竟然同时也是艺术家,吉他手,Garden City RubyConf 组织者.本文是 DIY Ruby CPU Profiling 的第二 ...

  2. DIY Ruby CPU 分析——Part III

    [编者按]作者 Emil Soman,Rubyist,除此之外竟然同时也是艺术家,吉他手,Garden City RubyConf 组织者.本文是 DIY Ruby CPU Profiling 的第二 ...

  3. Windows上的Java线程CPU分析

    本文将为您提供一个教程,介绍如何在Windows OS上快速查明Java线程贡献者与CPU严重问题有关. Windows与Linux,Solaris和AIX等其他操作系统一样,使您可以在进程级别监视C ...

  4. jstack: Java占用高CPU分析之- C2 Compiler Thread

    1. 现象 应用刚上线时发现Java进程占用了大量的CPU份额,但过了几分钟后会降下来(流量没变的情况下),因为已经做了负载均衡,于是拿一台实例重新部署代码上线来分析.具体分析步骤参考另外一篇文章&l ...

  5. JAVA内存分析:使用JDK自带工具进行内存和CPU分析及垃圾回收

    JAVA内存分析:使用JDK自带工具进行内存和CPU分析及垃圾回收 JAVA内存分析一:基于dump内存溢出快照分析 JAVA内存分析二:idea集成jprofiler查看JVM内存使用情况 JAVA ...

  6. 3D打印机(Prusa I2)DIY经验分享(Part II)

    3D打印机(Prusa I2)DIY经验分享(Part II) 说明:QQ空间好像不是所有人都能访问,所以把文章搬到这里分享. 原文链接(QQ空间):https://user.qzone.qq.com ...

  7. Node.js 应用故障排查手册 —— 利用 CPU 分析调优吞吐量

    楔子 在我们想要新上线一个 Node.js 应用之前,尤其是技术栈切换的第一个 Node.js 应用,由于担心其在线上的吞吐量表现,肯定会想要进行性能压测,以便对其在当前的集群规模下能抗住多少流量有一 ...

  8. 08-09 性能测试--CPU分析

    Linux 监控工具 top:展示所有进程信息 vmstat:展示系统活动,硬件和系统信息 vmstat pid 10 ps: ps aux | sort -k3nr | head -n 10:展示 ...

  9. CPU分析系列--vmstat/pidstat -wt分析进程/线程上下文切换造成的性能瓶颈

    目录 1.从系统层面看:vmstat 1 3 2.从进程层面看:pidstat -w 3.从线程层面看上下文切换:pidstat -wt 4.案例: 1.使用sysbench模拟多线程切换. yum ...

最新文章

  1. 搞事情 -- python之线程
  2. 使用树莓派和kali Linux打造便携式渗透套件
  3. 微信小程序 子组件调用父组件方法
  4. JQuery:deferred对象的方法
  5. mysql主从复制时间配置_MySQL主从复制配置
  6. js 判断浏览器是否64位
  7. 时间特效。js读取时间
  8. assertion failed:concurrent update to the log .mutiple streaming jobs delete 4
  9. sql server生成不重复的时间字符串
  10. 1、eclipse 使用git提交项目至github进行项目托管
  11. eclipse新建服务器项目,使用eclipse快速新建spirngboot项目的方法
  12. Python使用python-snap7实现西门子PLC通讯
  13. 7号信令: TUP与ISUP的区别
  14. eclipse java类图_Eclipse下生成/编辑Java类图或时序图(UML)[转载]
  15. 物联网安全行业调研报告 - 市场现状分析与发展前景预测
  16. hdu 6437 Videos 最小费用最大流
  17. 计算机黑屏启动超慢,电脑开机慢黑屏时间长怎么解决
  18. php新闻删除功能设计,PHP开发 新闻发布系统之新闻删除页面
  19. git基础之切换分支
  20. 王治洪个展上野森美术馆隆重开幕

热门文章

  1. mount: unknown filesystem type 'LVM2_member'解决方案
  2. 实现分页的通用存储过程
  3. 循环队列及C语言实现三
  4. [react] 为什么说React中的props是只读的?
  5. 前端学习(3309):redux项目创建和概况
  6. Taro+react开发(38)注意请求接口的/
  7. Taro+react开发(37)箭头函数括号加个return
  8. [软技能] 请说说使用iconfont图标的优点和缺点
  9. [vue-cli]vue-cli3插件有写过吗?怎么写一个代码生成插件?
  10. 工作163:eachrt修改