Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1188802
  • 博文数量: 253
  • 博客积分: 5892
  • 博客等级: 大校
  • 技术积分: 1942
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-24 14:20
文章分类

全部博文(253)

文章存档

2012年(98)

2011年(155)

分类: LINUX

2011-12-24 23:53:21

翻译:飞哥 ()

版权所有,尊重他人劳动成果,转载时请注明作者和原始出处及本声明。

原文名称:《Linux Performance and Tuning Guidelines》

原文地址:

-------------------------------------------------------------------------------------------

本章将讲解怎样发现影响服务器的性能问题。我们总结了一系列步骤来指引你完成恢复服务器到一个可以接受的性能等级的具体方案。

本章报告以下内容:

▶ 3.1,“确认瓶颈”

▶ 3.2,“CPU瓶颈”

▶ 3.3,“内存瓶颈”

▶ 3.4,“硬盘瓶颈”

▶ 3.5,“网络瓶颈”


《Linux 性能及调优指南》3.1 确认瓶颈

-------------------------------------------------------------------------------------------

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

1. 了解你的系统。
2. 备份系统。
3. 监控和分析系统性能。
4. 缩小瓶颈范围,找出原因。
5. 修复导致瓶颈的原因,每次只做一个变更。
6. 回到第3步,直到系统性能达到满意。

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

3.1.1 搜集信息

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

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

- 型号
- 使用年限
- 配置
- 外围设备
- 操作系统版本和更新等级

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

- 都有哪些症状?
- 描述一下错误信息。

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

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

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

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

▶ 问题是否可以重现?

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

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

- 重现问题需要哪些步骤?

知道这些步骤可以帮助你在相同条件下不同的机器中再现相同的问题。如果可以,你将有机会使用测试机来代替崩溃的生产服务器。

- 是一个间歇性问题吗?

如果问题间歇性发生,第一件要做的是就是搜集信息并找到可以重现问题的规律,目标就是构建一个情境让问题可以随时发生。

- 问题在每天的特定时间或每周的特定某天发生吗?

这可能帮助你查明问题是由什么引起的。问题可能发生在大家上午上班或下午上班时,想办法改变现有作息时间(这可能减少问题发生的机会或发生的更加频繁);以便让问题可以重现。

- 问题很少见吗?

如果问题不可以重现,你可能得出结果在特殊情况下问题才会发生并将其归类为已解决。在现实生活中,此问题还是极有可能再次发生的。

在排除难以重现的问题时,有效的措施就是:重启或将机器的驱动程序和补丁升级到最新。

▶ 问题是什么时候开始的?是渐渐的还是突然发生的?

如果性能问题是渐渐出现的,这很像是一个容量规划问题;如果它是突然出现的,很可能是由于服务器或外围设备的变更引起的。

▶ 服务器是否有做过变更(小的或大的)或客户端使用服务器的方法有改变吗?

- 客户是否改变过服务器或外围设备而导致了问题的发生?有网络变更的所有记录吗?

需求会随着业务的改变而改变,影响对服务器和网络系统的需求。

▶ 还涉及了其它的服务器或硬件吗?

▶ 有日志可以用吗?

▶ 问题的优先级是什么?什么时候问题必须解决?

- 必须在几分钟内解决还是允许在几天内解决?你可能有充分时间来解决问题;或已启动应急方案。

- 问题有多大?

- 相关的损失有哪些?

3.1.2 分析服务器性能

重要提示:在执行任何故障排除动作前,备份所有的数据和配置信息,防止其部分或全部丢失。

此时,你应开始监控服务器。最简单的方法就是在需要分析的服务器上运行监控工具。(参看第二章“监控和基准工具”)。

在运行高峰时(例如,上午9点到下午5点)记录服务器的性能日志;取决于有提供哪些服务和有哪些人在使用这些服务。在记录日志时如果可以应该包含下列字段:

处理器【Processor】
系统【System】
服务器工作队列【Server work queues】
内存【Memory】
分页文件【Page file】
物理硬盘【Physical disk】
重定向器【redirector】
网络接口【Network interface】

在你开始前,要牢记井然有序的进行性能调优是非常重要的。你可以使用我们推荐的流程为你的服务器进行调优,流程如下:

1.清楚影响服务器性能的因素。

2.测量出当前的性能作为基线,用于与后来的测量数据比较来识别出系统的瓶颈。

3.使用监控工具来识别性能瓶颈。按照下节介绍,你可以缩小瓶颈的范围到子系统级。

4.针对导致瓶颈的元件执行相应调整,提升服务器性能以满足需要。

注释:当服务器其它元件都有足够的能力来维持性能在一个较高的级别时,通过升级存在瓶颈的元件可以获得最好的效果。

5.对性能进行新的测量,对比调优前后的性能差异。

当尝试处理性能问题时,请记住下列事项:

▶ 应用程序应该使用适当的优化级别进行编译,这样可以少走弯路。

▶ 在你做任何升级和修改前执行测量,以便于确定变更是否有效果。(换句话说就是执行基线测量)

▶ 检查项目不应只有新增加的硬件,还要包括配置有更改的现有设备。



阅读(1023) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~