Linux 系统的性能评估和调优指南

　　对服务器来说主要的角色就是应用服务器或数据库服务器，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的负载。

　　下面的步骤可用来作为快速调优的策略：

　　1. 了解你的系统。

　　2. 备份系统。

　　3. 监控和分析系统性能。

　　4. 缩小瓶颈范围，找出原因。

　　5. 修复导致瓶颈的原因，每次只做一个变更。

　　6. 回到第3步，直到系统性能达到满意。

　　提示：你应该将每一个步骤记录在文件中，特别是你针对性能所做的变更和及其影响。

　　3.1.1 搜集信息

　　大多数情况下，你所能得到的第一手信息就是“服务器出现了问题”。所以利用一些探索性问题来弄清和记录下问题是非常重要的。这里列出一些问题用来帮助你更好的了解系统。

　　▶ 你能给我关于所涉及服务器的完整信息吗?

　　- 型号

　　- 使用年限

　　- 配置

　　- 外围设备

　　- 操作系统版本和更新等级

　　▶ 你能告诉我究竟出现了什么问题?

　　- 都有哪些症状?

　　- 描述一下错误信息。

　　对于有些人回答这个问题有些困难，但用户提供的任何额外信息都有可能帮助你找到问题。例如，用户可能说“当我拷贝文件到服务器时速度真的很慢。”。这就暗示网络有问题或硬盘子系统有问题。

　　▶ 谁受到这个问题的影响?

　　一个人、某些人还是整个组织受这个问题的影响?这可以帮助你判断问题是否出现在某段特定的网络中还是与应用相关等等。如果只有一个用户受此问题影响，很可能是用户的PC出了问题(或者是他们想象出来的)。

　　The perception clients have of the server is usually a key factor.从这个观点来说，性能问题并不一定与涉及服务器直接有关：位于服务器和客户端的网络极易成为导致问题的原因，这包括网络设备和其他提供服务的服务器，例如域控制器。

　　▶ 问题是否可以重现?

　　所有可以重现的问题都能被解决。如果你在系统方面经验丰富，你应该能找出问题根源并采取相应的措施。

　　问题的重现可以让你更好的了解和明白此问题。记录重现问题的相关步骤是十分必要的：

原文转自：http://www.redbooks.ibm.com/abstracts/redp4285.html