当前位置：文档之家 › Informix 性能调优实例讲解

Informix 性能调优实例讲解

  • 格式：docx
  • 大小：91.65 KB
  • 文档页数：6

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

性能优化原则
包括：
∙性能规划：深入了解应用与数据库的交互特征，确立良好的设计、开
发、测试迭代过程，上线前消除模型上的性能瓶颈。

∙实例调优：建立性能基准，对比调节数据库、操作系统、存储、网络
等的配置，主动监控、消除瓶颈。

∙SQL 调优：书写高效SQL，优化相关数据库对象，充分借助优化器，
确定最佳执行计划。

性能优化流程
1. 首先执行下面的初始检查：
o获取直接用户的使用反馈，确定性能目标和范围。

o获取性能表现好与坏时的操作系统、数据库、应用统计信息。

o对数据库做一次全面健康检查。

2. 根据收集的信息，以及对应用特性的了解，构建性能概念模型，明确
性能瓶颈所在，以及导致性能的根本原因。

o首先应该排除操作系统、硬件资源造成的瓶颈。

o然后针对数据库系统性能进行分析
o必要时，还需要检查应用日志，因为系统性能问题也可能由于应用非SQL 部分造成瓶颈。

3. 提出一系列针对的优化措施，并根据它们对性能改善的重要程度排序，
然后逐一加以实施。

不要一次执行所有的优化措施，必须逐条尝试，逐步对比。

4. 通过获取直接用户的反馈验证调节是否已经产生预期的效果，否则，
需要重新提炼性能概念模型，直到对应用特性了解进一步准确。

5. 重复上述，直到性能达到目标或由于客观约束无法进一步优化。

当从操作系统层面判断系统存在瓶颈并且是数据库引起的，那么可以从下面的流程图来解决
图 1. 性能诊断优化流程
典型性能问题案例
案例1：数据库应用突然变慢
问题特征
数据库应用突然变慢，查看系统信息，发现CPU 空闲突然很低，IO 性能没有明显恶化。

处理步骤
首先，需要排除操作系统上其他应用程序的问题。

通过top(HP)/topas(AIX/Linux) 命令可以看到当前占用CPU 资源最多的进程，确认是oninit进程。

Solaris 上默认没有top 命令，可以通过/usr/ucb/ps –aux | more 的方式来查看，该输出是根据CPU 占用情况来排序的。

数据库进程占用了大量CPU 资源时，往往是在对大表在做全表扫描。

通过 4.1 中的办法初步确认问题SQL 后，如果是条件查询SQL，如带WHERE 条件的SELECT /UPDATE /DELETE，还可以通过得到具体的SQL 查询计划来确认是在进行全表扫描。

此时需要对比dbschema得到的建表脚本，看是否建立了相应的索引，如果没有合适的索引，应该创建；如果应用没有合理应用已有索引，应该考虑修改应用SQL。

如果表上有合适的索引，应用SQL 也没有问题，那么就有可能是由于表中数据已经变化较大而长时间未对表收集统计信息，造成数据库引擎选择了错误的查询计划。

此时应该对该表收集统计信息后，通常可以收到良好的效果。

有时候问题SQL 还会是INSERT 语句，此时通常需要查看表的建表脚本，看看表上是否有过多的索引，是否该表上有不适当的外键指向另一个大表，也可以通过适当删除表中的记录来实现优化。

易出现时机
新应用/ 新模块投入运行
案例2：检查点持续时间突然显著增加
问题特征
数据库应用突然变慢，查看系统信息，发现CPU 空闲突然很低，IO 性能明显恶化。

和问题1 的显著不同在于，此时IO 恶化现象非常明显。

Vmstat显示b(block) 很大，有很多等待IO 的进程，sar显示wio明显超过平时值。

观察数据库日志，发现数据库检查点持续时间(checkpoint duration time) 显著增加，平时在3 秒以内就能完成，此时需要10 秒甚至更长时间才能完成。

处理步骤
首先还是查看数据库日志和操作系统日志，排除数据库内部错误和操作系统IO 错误。

如果用的是阵列(RAID)，最好再查看一下阵列的日志，出现这种情况最常见的原因是阵列出了问题，比如电池没电，cache 没有打开等等。

排除了操作系统和数据库内部错误，就需要了解一下是否有新的应用在进行大批量的数据操作，如INSERT/DELETE/UPDATE，是否能将这些操作放在系统相
对空闲的时候进行。

对于大批量的数据导入操作，在INFORMIX9.4 中提供了RAW 类型的表，由于不记录逻辑日志，插入速度会快很多，导入完成后，再将表修改为正常模式；对普通表应该先导入数据，再创建索引，注意主键、外键默认都会创建索引，应该在数据导入后在创建。

不恰当的应用SQL 也会导致IO 量非常大，可以用案例 1 中的办法来找到问题SQL，根据实际情况进行处理。

易出现时机
∙新应用/ 新模块投入运行
∙阵列、存储的硬件问题
案例3：检查点持续时间逐渐缓慢增加
问题特征
数据库稳定运行一段时间后，性能开始下降，检查点持续时间(checkpoint duration time) 开始逐渐增加，系统CPU 空闲降低，WIO 有所增加。

这些情况往往出现在新的应用上线后一段时间，由于在开发和测试环境中数据量小，性能问题不会暴露，当生产环境数据量增长到一定程度后，性能问题就会出现。

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

利用4.2 中描述的办法找到被顺序扫描多次的大表及其上的问题SQL，进行分析，采取相应办法尝试减少其上的顺序扫描：
∙创建相应索引；
∙修改应用SQL；
∙及时删除表中不必要的数据。

合集下载

nginx或tomcat的性能优化调整详解

nginx或tomcat的性能优化调整详解

nginx或tomcat的性能优化调整详解性能优化对于服务器来讲肯定是做得越合理越好了，下文我来为各位整理一篇关于nginx或tomcat的性能优化调整例子，有兴趣的朋友不防和小编一来看看吧。

最近花了一点时间进行了NGINX加TOMCAT7集群压力测试，下面通过对一些常见问题的回答来说明如何调优服务器的性能，是自己的一些经验，且无实际数据，如有纰漏请见谅。

背景: TOMCAT7已加APR或者NIO。

已装简单监控JCONSOLE,监控服务器内存，线程等基本情况。

问题1 一个Tomcat他的maxThreads到底配置多少合适?一个好的maxThreads的配置就是达到资源的合理化应用。

资源池：在讲其它东西之前，我们先引入一个概念，就是资源池。

tomcat7中，他对http请求的处理，也有一个池的概念，配置可以参考这里。

每一个请求进来后都是使用线程池中的一个来处理，线程池的大小是由maxThreads来限定的。

异步IO：当前Tomcat通过使用JAVA NIO或者Apache Portable Runtime这样的异步IO来支持性能的优化。

异步IO就是当应用需要进行耗时的IO操作时，向内核发出请求，不用真正等IO操作完成，就去处理其它的请求了，当IO真正完成时会有回调或通知机制通知并完成余下工作。

而一般的同步IO是当应用需要IO操作时，向操作系统发出IO Read/Write 请求。

同时阻塞当前应用，并等待IO返回，返回后才进行后续的操作。

从这里可以看出异步IO实际是将请求的处理和IO处理并行了，这样自然能较大的提高系统的吞吐量。

maxThreads的大小:第一点：从上面的异步IO的机制来看，实际上我们可能可以用一个很小的线程池处理较大的连接数。

如当前有100个请求要被处理，处理过程中50个进程都处于IO等待的状态，所以我们实际可能只需要50就能够处理那些不处于IO等待状态的请求就能满足需要了。

注意在Tomcat中是使用maxConnection这个配置参数来配置Tomcat的同时处理连接数的。

轻松掌握Informix多方面的参数设置对性能的影响-电脑资料

轻松掌握Informix多方面的参数设置对性能的影响-电脑资料

轻松掌握Informix多方面的参数设置对性能的影响-电脑资料注释：（应使用原始磁盘空间，不要使用文件系统空间，。

）原始磁盘空间意味着通过一个字符模式特殊文件（在ls -l 命令显示的第一列总出现的一个'c')访问一个原始磁盘分区，不是指磁盘空间相关联的块模式特殊文件（为ls -l 命令显示的第1列为'b')，也不是指卷管理控制设备以及其它任何不是原始磁盘分区的设备。

更新统计这是十分重要的。

当相关各列上的数值分布发生明显变化时，适时运行UPDATE STATISTICS命令后能使数据分布和统计数据得到更新。

对建有索引的列运行UPDATE STATISTICS HIGH，对其它所有列使用UPDATE STATISTICS MEDIUM.由于UPDATE STATISTICS处理的内部并行程度低，因而使用多个并发任务进行更新统计会改善全局的吞吐量。

可能需要增加DBUPSPACE 环境变量的值。

预读对非并行顺序扫描（只对数据、只按索引，按索引/数据）十分有用。

通过onstat -p监测。

如果ixda-RA,idx_RA及da_RA的总和与RA-pgsused接近，则要增加预读参数，如果它们的总和远远小于RA-pgsused,则要减小相应参数，通常保持RA_PAGES<=32,并使RA_THRESHOLD大约等于PA_PAGES的一半。

OLTP与DSSOLTP的特点:用户多高事务率在数据处理方面，事务相对较小明显的页操作（插入/更新/删除）通过索引的快速数据访问高度使用缓冲区快速缓存并行范围有限DSS特点涉及大量数据很少的写操作（除临时空间和数据加载之外）用户相对较少处理大批数据的大量、复杂查询主要通过顺序扫描访问数据并行范围广磁盘分布与分片磁盘硬件的选项：传输速度高，定位时间少大量的小盘比少量的大盘好避免控制器过载将Online磁盘空间与其它系统操作分开文件系统交换空间将物理、逻辑日志分开对于有大量的写操作（插入、更新、删除）的任何Online应用环境应将逻辑和物理日志分别放在不同的磁盘/控制器上。

调优informix数据库

调优informix数据库

调优informix数据库转⾃简介最近，我遇到了很多与性能相关的问题，因此，我想我应当针对这⼀问题做⼀些解释。

由于懒于整理⾃⼰的基准，⽽且我认为剖析⼴泛使⽤的基准更有意义，因此我们来研究⼀下与 Advanced DataTools 所采⽤的 “Fastest DBA 基准”。

⼤多数读者对此可能并不太熟悉，这是⼀个由 Advanced DataTools 发起的定期辩论，他们提出了⼀个缓慢运⾏的应⽤程序，让挑战参与者来对其进⾏调优。

我在部分提供了这⼀讨论相关细节的链接。

我也意识到类没有书⾯⽂字有⽤，因此，您现在所阅读的是对于如何基于 Fastest DBA 基准的剖析，来调优数据库的探索。

我们将执⾏基准、注意性能问题，单独解决每个问题，并使⽤所有已解决的问题来尝试该基准。

注意这是第⼆个基准；后续的⽂章将会对第三个（以及当前的）基准进⾏剖析。

本⽂不介绍有关基准的安装问题 — README ⽂件当中提供了全⾯的讲解。

我在我的 MacBook 中提出了两个问题，第⼀个是关于引擎的SHMBASE。

我必须编写源⽂件 $ONCONFIG，并进⾏相应的设置（并针对每个 setup.sh 执⾏进⾏重新复制）。

第⼆个问题是，我的Informix ⽤户默认属于 “admin” 组，因此，我必须⼿动将 dbspaces 的所有权改为 Informix:Informix。

基准的执⾏与交付⽆法及时完成。

基准本⾝很简单：它加载客户表，然后为这些客户⽣成账单。

最后的操作是对账单表的更新，这需要花费⼀定时间。

该⼯作并不复杂，但它提供了⼀个认识调优如何提⾼性能的机会。

从哪⾥开始？通常，任何性能调优项⽬的⾸要问题是问题描述。

如何知道何时已经解决了问题？如何衡量性能以及确定它是否已被提⾼，以及提⾼了多少？基于本⽂的⽬的，我想说，基准的运⾏时间过长，我想在⼀个⼩时内执⾏完毕。

此外，我会捕获每个阶段的数据库指标来确定是否有所改善。

有关数据库调优的第⼆个问题是确定调优什么。

数据库(informix)优化和备份策略方案指导

数据库(informix)优化和备份策略方案指导

NIOS DB(Informix)数据库优化和备份策略方案指导亿阳信通服务支持中心2011年05月版权所有本产品或文档受版权保护，其使用、复制、发行和反编译均受许可证限制。

未经亿阳及其授权者事先的书面许可，不得以任何形式、任何手段复制本产品及其文档的任何部分。

目录目录 (3)第一章前言 (4)1.1目的41.2内容41.3谁应该读这本书 (4)第二章 NIOS数据库优化 (5)2.1 基本DBS优化和调整 (5)2.2 Informix onconfig参数配置 (7)2.3 表结构及分片策略优化 (29)2.4 应用索引的优化 (30)第三章 NIOSDB备份和容灾策略 (32)3.1.备份策略和容灾 (32)3.2 .高可用性 (32)3.3. 数据压缩 (33)第四章常用提高性能的注意事项和出错查询 (33)4.1 合理利用索引 (33)4.2 SQL技巧 (33)4.3 View, PDQ, Stored Procedure, and Trigger (34)4.4表被索处理 (34)4.5查询主键重复 (35)第一章前言1.1目的随着网优项目的推进，对数据粒度和范围需求造成数据量急剧膨胀。

对原数据库构架不合理会造成难以适应生产的需要，对数据库进行格式优化就尤为重要，同样使用话务网管数据库的改造，根据现场情况，因地制宜的进行改造，会大大降低维护成本，提高生产效率。

1.2内容针对省级网优系统服务程序的要求，本指导描述了对INFORMIX 11.5 以上版本的优化关键点，以及备份和容灾参考，保障生产需要：*数据库版本建议*DBS空间划分改造的指导建议*系统配置*onconfig文件参数的修改建议*表结构及分片策略的建议*索引优化建议和参考*备份和容灾方案建议1.3谁应该读这本书本指导适合在现场有一定维护经验，对INFORMIX维护达到中级维护水平。

并熟悉操作系统和有基本的数据库开发经验。

第二章 NIOS数据库优化此章介绍Informix 11.5优化指导内容：优化前准备⏹INFORMIX版本升级需要由于INFORMIX在技术升级和改造中，FC7版本以上相对问题比较少，建议INFORMIX升级到11.5FC7以上。