CPU瓶颈

• CPU瓶颈
  • 找出CPU瓶颈
  • SMP
  • 性能优化选项
    对于应用或数据库服务器来说，CPU是十分关键的资源，也常常是性能瓶颈的源头。需要明白的是，高的CPU利用率并不总是意味着CPU正在繁忙的工作；也可能是正在等着其它子系统完成工作。正确的判断，需要把整个系统作为一个整体，并且观察到每一个子系统，因为子系统可能存在关联的反应。

在普遍的认知中，总是误以为CPU是服务器最重要的部件。但情况并不总是这样，在服务器上配置的CPU总是好于磁盘、内存、网络等子系统组件。只有特定的CPU密集型程序才能正真利用到今天的高端处理器。

找出CPU瓶颈

有好几种办法可以确认瓶颈出现在CPU上。已经在第二章"监控和测试工具"中讨论过了，Linux有各类工具来帮助我们。关键是选择什么工具。

可以使用uptime。通过分析uptime的输出，可以粗略知道在过去15分钟里，服务器上发生了什么。关于这个命令的更多解释，参考uptime这一节。

使用KDE System Guard和CPU传感器可以看到当前CPU负载。

小贴士：一次不要运行太多工具，避免增加CPU的问题。一次运行太多不同的监控工具，可以导致CPU负载飙升。

使用top工具，你可以看到CPU利用率和哪个进程是消耗CPU的大户。如果设置了sar，你会收集到很多信息，比如一段时间内的CPU利用率。分析这些信息的办法可能不同，使用isag，可以对sar的输出画出图形。你还可以通过脚本和表格来分析信息，看看CPU利用率的走向。你也可以在命令行使用sar -u或者sar -U processornumber。要想获得系统更全面情况，而不只是CPU子系统，vmstat是个好帮手。

SMP

基于SMP的系统呈现出来的问题可能是很难检测到的。在SMP环境中，有一个CPU affinity的概念,表示绑定进程到CPU上。这么做的主要好处是CPU缓存优化，可以让同样的进程运行在一个CPU上，而不是在多个CPU上切换。当进程在CPU间切换的时候，要刷新新的CPU的缓存。进程在处理器间切换的时候会导致很多缓存刷新，那样，一个独立的进程要花费更多的时间才能处理完。而探测器很难检测到，在监控中，CPU负载会十分均衡，不会在任何一个上出现高峰。在基于NUMA的系统上，比如IBM System x3950上，CPU affinity也很有用，重要的是保持内存、缓存和CPU访问都是本地的。

性能优化选项

第一步是要确保，系统性能问题是由CPU引起的，而不是其它子系统。如果处理器是服务器瓶颈，可以采取如下的办法来增强性能：

• 使用ps -ef来确保没有不必要的进程程序在后台运行，如果找到了这样的程序，关掉它，或者使用cron让它在非高峰的时候运行。

• 通过top找到非关键的、CPU密集型进程，然后用renice修改它的优先级。

• 在基于SMP的机器上，尝试使用taskset命令绑定进程到CPU上，避免进程在多个处理器之间切换，引起cache刷新。

• 基于运行的应用，确认你的应用是否能高效的利用多处理器。来决定是否应该使用更强劲的CPU而不是更多的CPU。例如，单线程应用，会从更快的CPU中受益，增加值CPU个数也没用。

• 还有其它办法，比如，确保你使用的是最新的驱动和固件，这能影响到他们在系统上的负载。

原文: https://lihz1990.gitbooks.io/transoflptg/content/03.分析性能瓶颈/3.2.CPU瓶颈.html