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

作者：网络转载发布时间：[ 2013/3/4 14:13:52 ] 推荐标签：

　　对服务器来说主要的角色是应用服务器或数据库服务器，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. 缩小瓶颈范围，找出原因。