版权所有，尊重他人劳动成果，转载时请注明作者和原始出处及本声明。
原文名称：《Linux Performance and Tuning Guidelines》
原文地址：http://www.redbooks.ibm.com/abstracts/redp4285.html
-------------------------------------------------------------------------------------------
对服务器来说主要的角色就是应用服务器或数据库服务器，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的负载。