我怎样才能测量在Linux的真正的CPU使用情况？ [英] How can I measure real cpu usage in linux?
问题描述
我知道有一些工具可以用来测量CPU使用率，例如 top 和 ps ，但是它们衡量CPU使用率的方式是测量空闲任务的时间没有运行。因此，例如，即使CPU因高速缓存未命中而失速，这些工具仍会考虑占用CPU。但是，我想要的是分析工具在停转期间将CPU视为空闲。有没有什么工具可以做到这一点？
..测量CPU使用率是通过测量空闲任务没有运行多少时间。
不，它们不测量空闲，他们只是通过/ proc / stat读取内核对其CPU使用情况的看法（try vmstat 1 工具）。您是否检查过系统范围内的用户+系统时间仅由闲置？我认为，内核只是导出一些调度程序的统计信息，这些调度程序在系统定时器和阻塞系统调用（可能是 update_curr 例如：
$ b
cat / proc / stat
cpu 2255 34 2290 22625563 6290 127 456
并通过 http://www.linuxhowtos.org/解码System / procstat.htm
第一个cpu行汇总了所有其他cpuN行中的数字。这些数字表示CPU花费在执行不同类型工作上的时间。时间单位为USER_HZ或 Jiffies （通常为百分之一秒）。
列的含义如下，从左到右：
user：以用户模式执行的普通进程
nice：执行的进程在用户模式下
system：在内核模式下执行的进程
idle：旋转的大拇指
当我们听到jiffie时，它意味着调度程序用于获取数字，而不是估计 idle 任务（顶部甚至没有看到此任务或带有pid 0的任务） 。
$ b
因此，例如，即使CPU由于缓存未命中而失速，这些工具仍会认为CPU是占据。
基本上（当没有 SMT ，例如英特尔的HT），当任务由于内存访问而导致管道延迟时（或者采用无序的错误路径）时，CPU将被占用。 OS不能运行其他任务，因为任务切换更加昂贵，因此等待这一个停顿。
SMT的情况不同，因为有硬件或者切换两个逻辑单个硬件上的任务，甚至（细粒度SMT中）将它们的指令（微操作）混合到单个流中以在共享硬件上执行。通常有SMT统计计数器来检查实际混合。
然而，我想要的是分析工具将CPU视为闲置期间一个摊位。有什么工具可以做到这一点？
性能监控单元可能会为此提供有用的事件。例如， perf stat 报告了一些内容（在Sandy Bridge上）
$ perf stat / bin / sleep 10
'/ bin / sleep 10'的性能计数统计：
0,563759任务时钟＃0,000使用的CPU
1 context-switches＃ 0,002 M /秒
0 CPU迁移＃0,000 M /秒
175页错误＃0,310 M /秒
888 767周期＃1,577 GHz
568 603失速 - 周期 - 前端＃63,98％前端周期空闲
445 567 stalled-cycles-backend＃50,13％后端循环空闲
593 103指令＃每循环0.67次insins
＃0,96每个insn的停顿周期
115 709个分支＃205,246 M / sec
7 699分支未到＃所有分行的6,65％
10,000933734秒已用时间
因此，它说睡眠10使用了0.5 jiffie（任务时钟）。它太低而无法用经典rusage进行计算，而/ usr / bin / time得到0 jiffie作为任务CPU使用率（用户+系统）：
$ / usr / bin / time sleep 10
0.00user 0.00system 0：10.00elapsed 0％CPU（0avgtext + 0avgdata 2608maxresident）k
0inputs + 0outputs（0major + 210minor）pagefaults 0swaps
然后执行措施（在PMU的帮助下计数）实际周期和由任务执行的实际指令任务） - cycles 和指令行。睡眠使用了888k周期，但仅完成了593k条有用说明，意思是 IPC 为0.6-0.7（ 30-40％摊位）。大约30万个周期丢失;和在Sandy Bridge上 perf 报告丢失 - stalled-cycles - * 前端事件（解码器 - CPU don由于分支未命中或者由于代码没有被预取到L1I，所以不知道要执行什么操作）和后端（由于指令需要内存中的某些数据，而这些数据在正确的时间不可用 - 内存停顿），所以无法执行。
为什么我们在CPU内部看到更多的停顿，当没有执行任何指令时应该只有300k周期？这是因为现代处理器通常是超标量和乱序的 - 他们可以在每个CPU时钟周期开始执行几条指令，甚至对它们重新排序。如果您想查看执行端口利用率，请尝试从Andi Kleen的 ocperf （perf wrapper） rel =noreferrer> pmu-tools 和一些有关其PMU计数器的英特尔手册。还有 toplev.py 脚本，可以在不选择英特尔事件的情况下识别工作负载的微观架构瓶颈。
I know that there are tools like top and ps for measuring CPU usage, but the way they measure the CPU usage is by measuring how much time the idle task was not running. So, for example, even if a CPU has a stall due to a cache miss, these tools would still consider the CPU to be occupied. However, what I want is for the profiling tool to consider the CPU as idle during a stall. Is there any tool which does that?
tools like top and ps for measuring CPU usage, .. measure the CPU usage is by measuring how much time the idle task was not running.
No, they don't measure idle, they just read what kernel thinks about its CPU usage via /proc/stat (try vmstat 1 tool too). Did you check that system-wide user + system times are accounted only by idle? I think, kernel just exports some stats of scheduler, which records user/system state on rescheduling, both on system timer and on blocking system calls (possibly one of callers of cpuacct_charge, like update_curr - Update the current task's runtime statistics.).
/proc/stat example:
cat /proc/stat
cpu 2255 34 2290 22625563 6290 127 456
and decode by http://www.linuxhowtos.org/System/procstat.htm
The very first "cpu" line aggregates the numbers in all of the other "cpuN" lines. These numbers identify the amount of time the CPU has spent performing different kinds of work. Time units are in USER_HZ or Jiffies (typically hundredths of a second).
The meanings of the columns are as follows, from left to right:
user: normal processes executing in user mode
nice: niced processes executing in user mode
system: processes executing in kernel mode
idle: twiddling thumbs
When we hear jiffie, it means that scheduler was used to get the numbers, not estimating of idle task (top even don't see this task or tasks with pid 0).
So, for example, even if a CPU has a stall due to a cache miss, these tools would still consider the CPU to be occupied.
And basically (when there is no SMT, like HT in Intels), CPU is occupied when your task has pipeline stall due to memory access (or taking wrong path with out-of-order). OS can't run other task, because task switch is more expensive that waiting this one stall.
Case of SMT is different, because there is hardware which either switchs two logical tasks on single hardware, or even (in fine grained SMT) mixing their instructions (microoperations) into the single stream to execute on shared hardware. There are usually SMT statistic counters to check actual mixing.
However, what I want is for the profiling tool to consider the CPU as idle during a stall. Is there any tool which does that?
Performance monitoring unit may have useful events for this. For example, perf stat reports some (on Sandy Bridge)
$ perf stat /bin/sleep 10
Performance counter stats for '/bin/sleep 10':
0,563759 task-clock # 0,000 CPUs utilized
1 context-switches # 0,002 M/sec
0 CPU-migrations # 0,000 M/sec
175 page-faults # 0,310 M/sec
888 767 cycles # 1,577 GHz
568 603 stalled-cycles-frontend # 63,98% frontend cycles idle
445 567 stalled-cycles-backend # 50,13% backend cycles idle
593 103 instructions # 0,67 insns per cycle
# 0,96 stalled cycles per insn
115 709 branches # 205,246 M/sec
7 699 branch-misses # 6,65% of all branches
10,000933734 seconds time elapsed
So, it says that 0,5 jiffie (task-clock) was used by the sleep 10. It is too low to be accounted in classic rusage, and /usr/bin/time got 0 jiffie as task CPU usage (user + system): $ /usr/bin/time sleep 10 0.00user 0.00system 0:10.00elapsed 0%CPU (0avgtext+0avgdata 2608maxresident)k 0inputs+0outputs (0major+210minor)pagefaults 0swaps
Then perf measures (counts with help of PMU) real cycles and real instructions executed by the task (and by kernel on behalf of the task) - cycles and instructions lines. Sleep has used 888k cycles but only 593k useful instructions were finished, and mean IPC was 0.6-0.7 (30-40% stalls). Around 300k cycles was lost; and on Sandy bridge perf reports where they were lost - stalled-cycles-* events for frontend (decoder - CPU don't know what to execute due to branch miss or due to code not prefetched to L1I) and for backend (can't execute because instruction needs some data from memory which is not available at right time - memory stall).
Why we see more stalls inside CPU when there should be only 300k cycles without any instruction executed? This is because modern processors are often superscalar and out-of-order - they can start to executing several instructions every CPU clock tick, and even reorder them. If you want to see execution port utilization, try ocperf (perf wrapper) from Andi Kleen's pmu-tools and some Intel manuals about their PMU counters. There is also toplev.py script to "identify the micro-architectural bottleneck for a workload" without selecting Intel events by hands.
这篇关于我怎样才能测量在Linux的真正的CPU使用情况？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
