Chinaunix首页 | 论坛 | 博客
  • 博客访问: 8350400
  • 博文数量: 444
  • 博客积分: 10593
  • 博客等级: 上将
  • 技术积分: 3852
  • 用 户 组: 普通用户
  • 注册时间: 2006-05-09 15:26
文章分类

全部博文(444)

文章存档

2014年(1)

2013年(10)

2012年(18)

2011年(35)

2010年(125)

2009年(108)

2008年(52)

2007年(72)

2006年(23)

分类: DB2/Informix

2010-08-04 16:20:55

2008 年 10 月 21 日

在实际的生产运行环境中,笔者在国内很多客户现场都看到开发人员和系统管理人员遇到很多有关于 Informix 数据库引起的性能问题,进而被多次问起如何进行 Informix 数据库性能调优,笔者根据自己在工作中对 Informix 数据库的使用经验积累写下这篇文章。

在实际的生产运行环境中,笔者在国内很多客户现场都看到开发人员和系统管理人员遇到很多有关于 Informix 数据库引起的性能问题,进而被多次问起如何进行 Informix 数据库性能调优,笔者根据自己在工作中对 Informix 数据库的使用经验积累写下这篇文章。





回页首


包括:

  • 性能规划:深入了解应用与数据库的交互特征,确立良好的设计、开发、测试迭代过程,上线前消除模型上的性能瓶颈。
  • 实例调优:建立性能基准,对比调节数据库、操作系统、存储、网络等的配置,主动监控、消除瓶颈。
  • SQL 调优:书写高效 SQL,优化相关数据库对象,充分借助优化器,确定最佳执行计划。




回页首


  1. 首先执行下面的初始检查:
    • 获取直接用户的使用反馈,确定性能目标和范围。
    • 获取性能表现好与坏时的操作系统、数据库、应用统计信息。
    • 对数据库做一次全面健康检查。
  2. 根据收集的信息,以及对应用特性的了解,构建性能概念模型,明确性能瓶颈所在,以及导致性能的根本原因。
    • 首先应该排除操作系统、硬件资源造成的瓶颈。
    • 然后针对数据库系统性能进行分析
    • 必要时,还需要检查应用日志,因为系统性能问题也可能由于应用非 SQL 部分造成瓶颈。
  3. 提出一系列针对的优化措施,并根据它们对性能改善的重要程度排序,然后逐一加以实施。不要一次执行所有的优化措施,必须逐条尝试,逐步对比。
  4. 通过获取直接用户的反馈验证调节是否已经产生预期的效果,否则,需要重新提炼性能概念模型,直到对应用特性了解进一步准确。
  5. 重复上述,直到性能达到目标或由于客观约束无法进一步优化。

当从操作系统层面判断系统存在瓶颈并且是数据库引起的,那么可以从下面的流程图来解决




(点击查看大图)





回页首


问题特征

数据库稳定运行一段时间后,性能开始下降,检查点持续时间 (checkpoint duration time) 开始逐渐增加,系统 CPU 空闲降低,WIO 有所增加。这些情况往往出现在新的应用上线后一段时间,由于在开发和测试环境中数据量小,性能问题不会暴露,当生产环境数据量增长到一定程度后,性能问题就会出现。

针对这种情况,需要确认定期在对数据库,尤其是对数据库中的大表,在定期做收集统计数据的工作 (update statistics),避免数据量的增大造成系统性能急剧下降。

利用 4.2 中描述的办法找到被顺序扫描多次的大表及其上的问题 SQL,进行分析,采取相应办法尝试减少其上的顺序扫描:

  • 创建相应索引;
  • 修改应用 SQL;
  • 及时删除表中不必要的数据。




回页首


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