《Linux 性能及调优指南》3.2 CPU瓶颈

对服务器来说主要的角色就是应用服务器或数据库服务器，CPU作为关键资源经常成为性能瓶颈的根源。CPU使用率高并不总是意味着CPU工作繁忙，它有可能是正在等待其他子系统。在进行性能分析时，将所有子系统当做一个整体来看是非常重要的，因为在子系统中可能会出现瀑布效应。

注释：有种常见的错误观念认为CPU是服务器中最重要的。情况不总是这样，服务器经常是CPU的配置高，硬盘、内存和网络子系统是低配置。只有一些特定对CPU要求高的应用程序才能真正充分利用当今的高端处理器。

3.2.1 发现CPU瓶颈

有多种方法可以来确认CPU瓶颈。在第二章“监控和基准工具”中介绍到，Linux有很多工具帮助我们确认瓶颈，问题是使用哪一个。

其中一个工具是uptime。通过分析uptime输出，我能对在过去15分钟所发生的事情有个粗略的了解。关于此工具的更多说明，参见2.3.3“uptime”。

例子3-1：一个系统CPU资源紧张的uptime输出结果 ---------------------------------------------------------------------------------------- 18:03:16 up 1 day, 2:46, 6 users, load average: 182.53, 92.02, 37.95 ----------------------------------------------------------------------------------------

使用KDE System Guard和CPU传感器可以让你了解当前CPU的工作负载。

提示：小心不要因为同时运行过多的工具而导致CPU问题。你可能发现当同时使用多个不同监控工具时会使CPU负载过高。

使用top，你可以看到CPU使用率及主要是哪些进程引起问题（例子2-1）。如果你已安装sar，搜集了包括CPU使用率的信息。但分析这些信息是很困难的，所以要使用isag，它可以将sar的输出转换成图形。否则你可以通过脚本解析这些信息并使用电子表格绘制CPU使用率的趋势图。你也可以在命令行中输入sar -u或者sar -U processornumber。要获得比单单CPU子系统更多关于系统及当前使用率的信息，一个不错的工具就是vmstat（参见2.3.2，“vmstat”）

3.2.2 SMP

基于SMP的系统会出现其特有且难于检测的问题。在SMP环境中，有个叫CPU亲和力【affinity】的概念，它允许你将一个进程绑定到指定的CPU。

主要用途是这有利于CPU cache的优化，它通过让进程在同一CPU运行代替在处理器间移动来实现。当进程在CPU间移动时，新CPU的cache会被清空。因此一个进程在处理器间移动会发生多次cache清空，这意味着一个单独的进程会花费更多的时间才能完成。这种情况非常难于发现，因为在监控时CPU负载可能非常均衡，不一定会出现某个CPU达到峰值的情况。亲和力在基于NUMA的系统中也很有用如IBM System x 3950，where it is important to keep memory, cache, and CPU access local to one another.

3.2.3 性能调校选项

首先要确认系统性能问题是由CPU导致的而不是其他子系统。如果处理器为服务器瓶颈，可以通过相应调整来改善性能，这包括：

▶ 使用ps -ef命令确保没有不必要的程序在后台运行。如果发现有不必要的程序，将其停止并使用cron将其安排在非高峰期运行。

▶ 通过使用top命令找出非关键性且消耗CPU较多的进程，并使用renice命令修改它们的优先级。

▶ 在基于SMP的机器中，尝试使用taskset将进程绑定到指定的CPU，确保进程不需要在处理器间忙碌，从而导致多次cache清空。

▶ 对于正在运行的应用程序，最好的办法是纵向升级（提升CPU频率）而不是横向升级（增加CPU数量）。这取决于你的应用程序是否能使用到多个处理器。例如一个单线程应用程序的升级方式最好是更换成更快的CPU而不是增加为多个CPU。

▶ 通常的做法还包括确认你所使用的是最新的驱动程序和韧体，因为这会影响CPU的负载。