如果你在虚拟环境中，可能无法访问PMC，这要看虚拟机管理程序是否为访客（guest）支持PMC。我最近写过一篇文章：《EC2的PMC：测量IPC》（），表明了如今PMC如何可用于基于Xen的AWS EC2云上面的专用主机类型。

　　实际对策

　　如果你的IPC < 1.0，你可能遇到了内存停滞，软件调优策略包括减少内存输入/输出，改进CPU缓存和内存局部性（memory locality），尤其是在NUMA系统上。硬件调优策略包括：使用CPU缓存比较大的处理器以及速度比较快的内存、总线和互连技术。

　　如果你的IPC > 1.0，你可能是指令密集型。想方设法减少代码执行：消除不必要的工作和缓存操作等。CPU火焰图（）是一款很适合开展这项调查的工具。至于硬件调优，不妨试一试更快的时钟频率和数量更多的核心/超线程。

　　性能监测产品应该能告诉你什么？

　　每一款性能工具应该显示IPC以及%CPU。或者将%CPU分解成指令完成周期与停滞周期，比如%INS和%STL。

　　面向Linux的tiptop(1)可按进程显示IPC：

　　tiptop - [root]

　　Tasks: 96 total, 3 displayed screen 0: default

　　PID [ %CPU] %SYS P Mcycle Minstr IPC %MISS %BMIS %BUS COMMAND

　　3897 35.3 28.5 4 274.06 178.23 0.65 0.06 0.00 0.0 java

　　1319+ 5.5 2.6 6 87.32 125.55 1.44 0.34 0.26 0.0 nm-applet

　　900 0.9 0.0 6 25.91 55.55 2.14 0.12 0.21 0.0 dbus-daemo

　　CPU使用率具有误导性的其他理由

　　让CPU使用率具有误导性的不仅仅是内存停滞周期。其他因素包括如下：

温度过高导致处理器停滞。

睿频加速（Turboboost）导致时钟频率不一。

内核因speedstep导致时钟频率不一。

平均值方面的问题：1分钟内的使用率为80%，隐藏了100%的突发使用率。

自旋锁：CPU被使用，有很高的IPC，但是应用程序在处理指令方面没有合理的进展。

　　结束语

　　CPU使用率已成为一个极具误导性的度量指标：它包括了等待主内存的周期，而这类周期在现代工作负载中占了大头。如果使用额外的度量指标，你就能搞清楚%CPU到底意味着什么，包括每个周期指令（IPC）。IPC < 1.0可能意味着内存密集型，而IPC > 1.0可能意味着指令密集型。我在之前的一篇文章（）中介绍了IPC，包括介绍了衡量IPC所需要的性能监控计数器（PMC）。

　　显示%CPU的性能监控产品还应该显示PMC度量指标，解释那个值意味着什么，那样才不会误导最终用户。比如说，它们可以一并显示%CPU及IPC，以及/或指令完成周期与停滞周期。有了这些度量指标，开发人员和操作人员才能决定如何才能更好地调优应用程序和系统。