关于CPU使用率应用的误区和错误(译文)

转自7点: http://bbs.7dtest.com/thread-3668-1-1.html   译者： kaixin322        原作者：Chaitanya M Bhatt   谈起这个话题，盛行着很多误区、误解、错误观念。在这里，我将涉及到几个关键问题，并力争解释详细的事实及最佳做法。 错误的做法   获取对称式多处理器的服务器节点的系统级CPU使用率。（对称式多处理器：一个有多内核并且共享内存、总线和IO资源的CPU。）   大多数性能分析师或测试员通常的做法是：在压力测试期间，仅仅获取一个多内核服务器系统级的CPU使用率，就开始分析结果。用像LoadRunner这种工具获取你的UNIX/LINUX服务器系统的CPU使用率，是个非常大的误区。结果导致引起瓶颈原因的错误解析，错误的解决方案和为试图解决它而做的努力徒劳。   不同的软件，如数据库、中间件，拥有他们自己处理多核、多CPU的私有算法。   在负载均衡测试中，当你观察到系统CPU使用率在一个临界值下，这不总是意味着每个独立的内核都被平均加压。让我们举个例子：如果你注意到某个负载测试工具显示CPU使用率是25%，且假设这个服务器有四个处理器，这并不意味着所有的内核都被进程/线程平均负载。一个单独的内核可能被100%消耗了，而其他的内核则被100%闲置了。   使每个独立内核，平均或成比例的承担负载，依赖于应用程序的并行性，及测试软件是否有能力在SMP内核之间处理内部并行的查询。例如：Oracle支持内部并行查询。（例：在SMP模式下，把单一或独立查询的工作分给两个或更多内核处理，是可行的。）　而MySQL数据库则不提供此功能，结果独立查询将只被一个内核处理，即使这个CPU的使用率已经接近临界值。   另一个例子：你可能注意到，当执行负载测试时，一些和缓慢查询相关的事务，在数据库端奇异的失败了，即便CPU使用率在临界值内。现在，如果你深入挖掘这些缓慢查询，并把它和每个独立内核的CPU使用率相关联，你就可以看到，一些内核已经达到最大的１００％，而其他却仍然在临界值内。这就是引起该问题的本质原因。 相关链接： http://oreilly.com/catalog/oraclepp/chapter/ch01.html http://www.forsythesunsolutions.com/node/73 衡量独立内核／CPU使用率的推荐工具： Prstat （属性　－ｍ或-ml）：可用于Solaris操作系统。允许你衡量每个线程的CPU使用率。 mpstat: 可用于基于linux/unix的操作系统。（注：Mpstat是Sysstat工具的一部分） System Monitor:（系统监控） 基于界面的工具，可用于Red Hat Linux 操作系统。 相关链接： http://www.cyberciti.biz/tips/ho ... pu-utilization.html 错误的观念   监控工具显示的100%CPU使用率可能是误导。在这种情况下，我可以坦率的告诉你-'Seeing is not believing!'（看到的并非就是可信的）。你可能对着监控器抓破脑袋，苦思冥想，因为找不到可行方案，来解决所观察的某些服务器的高CPU使用率问题。你的服务器可能消耗100%使用率，而负载却不可思议的低。   然而，好消息是使用率100%，并不总是意味着CPU就是性能瓶颈，尤其是在UNIX/LINUX操作系统下。除非，你看到vmstat里‘r’值（进程队列），超出了SMP服务器的CPU数量。例如：如果r=5,而你的SMP只有4个CPU或内核，那这绝对是瓶颈。队列的意思是，如果CPU不忙，当一个线程进入运行/处理队列(r)时，它立即会被一个CPU处理。但是，如果所有可用的CPU都忙于处理线程，后来进入的线程就只能在进程队列中等待，直到有可用的CPU来处理这些等待的线程。 这说明，当你看到一个非常高的CPU值警报时，问问自己：CPU使用率是什么？ 答案：CPU使用率=100%-（%花在空闲业务的时间） 如果你理解了上述方程式，你就永远不会再在CPU使用率上迷失。 误区   上面提到的另一个误解是：高CPU使用率导致了缓慢的处理速度。   事实是：错。高CPU使用率不会拖慢应用程序处理速度。这只是另一个谬论。分析上诉方程式，并去除这个观念。CPU使用率和处理速度并无关系。   当到了分析和CPU严格相关资源的时候，工程师们往往忘记了，一个操作系统的调度或策划处理的基本法则是：确保CPU使用率在需要的时候尽可能的高。通常情况下，CPU运行在固定的时钟频率和固定速度的工作单位中。如果你理解了上述提到的规则，你就会意识到，处理速度和CPU使用率没有任何直接关系。无论CPU使用率是10%，还是100%，处理器总是会以相同的速度处理单位工作。只有当等待CPU处理的进程 /线程数总数，超过了SMP/服务器端所有可用的处理器时，线程/进程的执行速度才受影响。再次强调，下次在负载测试/性能测试时，不要忘记密切关注“r”（运行队列）值。 相关链接： http://blogs.sun.com/partnertech ... _process_monitoring http://www.dba-oracle.com/t_monitoring_unix_cpu.htm