电脑cpu负载过高怎么解决 cpu利用率多少正常( 二 ) _云知道

如果我们从 IPC的角度来看，这台机器只运行到其处理器最高速度的 19.5%（0.78 / 4.0) 。幸运的是，在处理器内部，有很多 PMU event，可用来帮助我们分析造成 CPU stall 的原因。用好 PMU 需要我们熟悉处理器微架构，可以参考 Intel SDM 。
4. 最佳实践是什么？如果 IPC < 1.0, 很可能是 Memory stall 占主导，可从软件和硬件两个方面考虑这个问题。软件方面：减少不必要的访存操作，提升 cache 命中率，尽量访问本地节点内存；硬件方面：增加 cache 容量，加快访存速度，提升总线带宽。如果IPC > 1.0, 很可能是计算密集型的程序。可以试图减少执行指令的数量：消除不必要的工作。火焰图CPU flame graphs，非常适用于分析这类问题。硬件方面：尝试超频、使用更多的 core 或 hyperthread 。作者根据PMU相关的工作经验，设定了1.0这个阈值，用于区分访存密集型(memory-bound)和计算密集型(cpu-bound)程序。读者可以根据自己的实际工作平台，合理调整这个阈值。
5. 性能工具应该告诉我们什么？作者认为，性能工具中使用 %CPU 时都应该附带上 IPC，或者将 %CPU 拆分为指令执行消耗 cycle(%INS) 和 stalled 的 cycle(%STL) 。对应到 top，在 Linux 系统有一个能够显示每个处理器 IPC 的工具 tiptop:

6. 其他可能让 CPU 利用率引起误解的因素除了访存导致的 stall 容易让人误解 CPU 利用率外，还有其他一些因素：

温度原因导致处理器 stall；
Turboboost 干扰了时钟速率；
内核使得时钟速率加快；
平均带来的问题：1分钟利用率平均 80%，掩盖了中间 100% 部分；
自旋锁: CPU 一直在被使用，同时 IPC 也很高，但是应用逻辑上并没有任何进展。

7. 更新：CPU 利用率真的错了吗?这篇文章引起了大量留言：

http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html 的留言栏;
https://news.ycombinator.com/item?id=14301739
CPU Utilization is Wrong fromprogramming

总结下作者的回答是：这里讨论的并不是 iowait (那是磁盘IO)，而且如果你已经确认是访存密集型，是有些处理办法（参考上面）。
那么 CPU 利用率指标是确确实实错误的，还是只是容易误导？如作者前面所说，他认为许多人把高 CPU 利用率理解为瓶颈在 CPU 上，这一行为才是错误的；
其实单看 CPU 利用率并不清楚瓶颈在何处，很多时候瓶颈是在外部。这个指标技术上看是否正确？如果 CPU stall 的周期并不能被其他地方使用，它们是不是也就因此是“忙于等待“（听起来有点矛盾）？在有些情况，确实如此，你可以说 CPU 利用率作为操作系统级别的指标技术上看是对的，但是容易产生误导。
从另一个角度来说，有超线程的情况下，那些 stalled 的周期是可以被其他线程使用的，这时 “%CPU” 可能会将可用的周期统计为正在使用，这种情况是错误的。这篇文章作者想关注的是解释清楚这个问题，并给出解决方法建议，但没错， CPU 利用率这个指标本身也是存在一些问题的。
当你可能会说利用率作为一个指标已经不对，Andrian Cockcroft之前讨论已经指出过 (http://www.hpts.ws/papers/2007/Cockcroft_HPTS-Useless.pdf ) 。
8. 结论【电脑cpu负载过高怎么解决 cpu利用率多少正常】CPU 利用率已经开始成为一个容易误导的指标：它包含访存导致的等待周期，这样会影响一些新应用。也许 “%CPU” 应该重命名为 “%CYC”（cycles的缩写）。要清楚知道 “%CPU” 的含义，需要使用其他指标进行辅助，其中就包括每周期指令数(IPC) 。IPC < 1.0 多半意味着访存密集型， IPC > 1.0 多半意味着计算密集型。作者之前的文章中涵盖有 IPC 说明，以及用于测量 IPC 的 Performance Monitoring Counters（PMCs）的介绍。所有的性能监控产品如果展示 “%CPU”，都应该同时展示 PMC 指标用于解释其真实意义，不要误导用户。比如，可以把 “%CPU” 和 “IPC” 一起放，或者说指令执行消耗周期和 stalled 周期。有这些指标之后，开发者和操作者就能够知道该如何更好地对应用和系统进行调优。