informix的性能优化
以下是我用INFORMIX DATABASE的一点体会,分享给大家,欢迎大家一起探讨!
1. 日志缓冲
如果不怕丢失几个事务则最好用缓冲日志,这样可以得到更好的性能.
如果数据安全性很重要,则最好用非缓冲日志.
2. DSS SERVER的优化有三个目标:
1>. 总查询通过量最大化
可以将ONCONFIG文件中的PDQPRIORITY设置限制小于25%
2>. 每个查询处理时间最小化
可以将ONCONFIG文件中的PDQPRIORITY设置限制大于50%
3>. 平衡优先级
可以将ONCONFIG文件中的PDQPRIORITY设置限制大于25%,小于50%
3. OLTP SERVER的优化有三个目标:
1>. 更新活动通过量最大化
使用缓冲日志
将检验点间隔最大化,周期最小化
可以将ONCONFIG文件中的PDQPRIORITY设置限制為0
增加物理日志长度
最大化写入缓冲百分比
其实以上的目标也是会矛盾的,关键在于如何取舍.
2>. 查询活动通过量最大化
最大化BUFFERS
可以将ONCONFIG文件中的PDQPRIORITY设置為0或1
最大化读取缓冲百分比
3>. 事务安全最大化
最小化CKPTINTVL
使用非缓冲日志
使用冗余磁盘和I/O路径
减少物理日志长度
4. 简单查询SERVER的优化有三个目标:
最大化BUFFERS,它一般>=40%RAM
可以将ONCONFIG文件中的PDQPRIORITY设置<25%
5. 内存问题
INFORMIX可以使用的内存是不限制的,给多少用多少,下面以IDS7.X為例:
缓冲区最多 768000 PAGES (OS 3GBW/4KB)
DSS内存最多1G
锁最多8000000
逻辑日志缓冲区 3个 LOGSIZE最大2G, TOTAL 6G
物理日志缓冲区 2个 PHYSFILE最大2G, TOTAL 4G
数据字典缓冲区 没有限制,可以调整参数DD_HASHSIZE和 DD_HASHMAX
onstat -g dic确定数据字典缓冲区是否接近容量
存储过程缓冲区 没有限制,可以调整参数PC_HASHSIZE和PC_POOLSIZE
onstat -g prc确定存储过程缓冲区是否接近容量
数据分布缓冲区 可以调整参数DS_HASHSIZE和DS_POOLSIZE
onstat -g dsc确定数据分布缓冲区是否接近容量
6. 磁盘问题
磁盘是越多越好的
多些驱动器比大的驱动器好
采取RAID磁盘阵列
7. 内核限制
不同的OS有不同的内核,这是可以调整的.
8. 内存参数
onstat -g seg确定共享内存分配和查询内存分区
SHMVIRTSIZE确保最低正常负荷内存,如果消息日志文件中表示动态新共享内存的消息很多,则要增加此参数的数值.
SHMADD至少应為SHMVIRTSIZE的10%
SHMTOTAL除非很小的系统,否则社為0让内存增长.
9. 分块表和大量区域
用oncheck -pt 和 oncheck -pe检查表的区域数及其在磁盘上的布局
一般说表格超过33个区域系统比较慢,可以压缩表格来解决
1>. 删除表格重建并重新装入数据
2>. 重新创建索引
3>. 将表和索引放在不同的DBSPACE
==============================================================================
Informix查询优化update statistics小注
给定查询的不同执行策略可能会有不同的代价，构造具有最小查询执行代价的查询执行计划是数据库系统的职责。查询优化是为了查询选择最有效的查询策略的过程。查询优化是尽量找出与给定表达式等价的、但是执行效率更高的一个表达式，而且决定执行运算时所采用的具体算法以及将使用的特定索引等。
为了在诸多查询策略中作出选择，数据库系统的优化器必须估计每个查询策略的代价，磁盘访问次数常常是衡量代价的主要标准。在没有按照某策略执行查询前，准确计算出该策略的代价是不可能的，所以，优化器要利用数据库系统中的统计信息，来估计查询策略的代价。Informix数据库系统这些统计信息保存在 SYSMASTER数据库中，
如果要维护准确的统计值，那么每当表数据修改时，相应的统计值也必须更新，这种更新会带来很大的代价，因此Informix系统不是在每次修改时对统计值更新。因此，用于选择查询策略的统计数据不一定完全正确，有时会遇到查询用不到应该使用的索引，就是统计信息没有更新的原因。对Informix数据库系统，这些统计信息保存在SYSMASTER数据库中，可以使用UPDATE STATISTICS命令更新。
以下是用于估计代价的信息：
<!--[if !supportLists]-->? <!--[endif]-->记录数
<!--[if !supportLists]-->? <!--[endif]-->表空间的页数
<!--[if !supportLists]-->? <!--[endif]-->记录长度
<!--[if !supportLists]-->? <!--[endif]-->字段不同值个数
<!--[if !supportLists]-->? <!--[endif]-->字段值的分布
<!--[if !supportLists]-->? <!--[endif]-->索引的层数
<!--[if !supportLists]-->? <!--[endif]-->索引叶结点数目
<!--[if !supportLists]-->? <!--[endif]-->索引B+树的深度
<!--[if !supportLists]-->? <!--[endif]-->索引是升序还是降序或聚类索引
<!--[if !supportLists]-->? <!--[endif]-->索引占用的页面数目
Informix 数据库服务器中的优化器为SQL语句的查询提供最有效的策略，这就使得你在进行表的连接查询时不必全面考虑究竟那个表首先搜索，以及究竟需要使用那个索引。
通过执行update statistics命令可以更新系统的统计信息，使得优化器得到当前最新的统计信息。当修改或删除一个表的相关数据时，系统的统计信息并不自动更新。比如：如果使用delete命令删除一个数据库表内的一条记录，删除完成后查找systables内关于该表的记录信息时，将会发现nrows（数据库表的记录行数目）并没有改变。而通过执行update statistics命令，就可以使系统表systables、sysdistrib、syscolumns、sysindexes等表内的信息得到更新。在运行完update statistics后，这时就会发现systables内的nrows字段已得到更新。如果执行update statistics medium（high），在sysdistrib表内还可以得到更新的数据分布信息。所以，当大量地修改数据库表后最好执行一下update statistics操作。另外，update statistics将强迫存储过程的优化（对sysprocpplan更新）。以下是与update statistics 相关的系统表：
1、syscolumns
描述了数据库内的每个字段，其中的colmin、colmax存储了数据库各表字段的次小及次大值，这些值只有在该字段是索引且运行了Update statistics之后才生效。如对于字段值1、2、3、4、5，则4为次大值，2为次小值。
2、sysdistrib：
存储了数据分布信息。该表内提供了详细的表字段的信息用于提供给优化器优化SQL Select语句的执行。当执行update statistics medium（high）之后将往此表存入信息。
执行“dbschema -hd”可以得到指定表或字段的分布信息
3、sysindexes：
描述了数据库内的索引信息。对于数据库内的每个索引对应一条记录。修改索引之后只有执行Update statistics才能使其改变在该表内得到反映。同时也更新clust的数值，在该表的数据页数目及数据库记录条数之间
4、systables：
通过执行Update statistics可以更新nrows数据
update statistics有以下三种级别：
1、LOW：
缺省为LOW，此时搜集了关于column的最少量信息。只有systables、syscolumns、sysindexes内的内容改变，不影响sysdistrib。为了提高效率，一般对非索引字段执行LOW操作
2、HIGH：
此时构建的分布信息是准确的，而不是统计意义上的。
因为耗费时间和占用CPU 资源，可以只对表或字段执行HIGH操作。对于非常大的表，数据库服务器将扫描一次每个字段的所有数据。可以配置DBUPSPACE环境变量来决定可以利用的最大的系统磁盘空间
3、MEDIUM：
抽样选取数据分布信息，故所需时间比HIGH要少
什么时候应该执行update ststistics ？
建议在以下情况，执行update statistics 操作：
对数据做了大量修改，大量是针对数据的分布而言，若数据分布没有明显的改变则可以不做改变的数据库表有与之相关的存储过程，避免在运行时存储过程重新优化数据库升级之后完成对索引的转变update ststistics 的方法
考虑到速度性能因素，执行update statistics的推荐方法：
对表执行：update statistics medium for table #### distributions only
对每个索引的首字段执行：update statistics high
对复合索引执行：update statistics low
必要时对非索引字段但在条件中使用到的字段执行Update statistics high操作
===================================================================
Informix 数据库优化
Informix IDS 数据库广泛的应用在金融、电信和邮政等各个行业中，它是一个多线程的关系数据库服务器，采用对称的多处理器技术和单处理器体系结构，并具有先进的技术、性能与高可靠性和高可用性。它为用户提供了动态系统管理工具来监控和管理数据库服务器。随着数据库数量的增加和应用处理交易量的增多，它的运行效率显得尤为突出。在硬件环境不变的情况下，数据库性能的提高也一直成为大家关注的话题。
数据库系统性能通常与 CPU、共享内存、数据的存储和网络设置等四个方面有直接的关系。下面着重介绍通过配置 Informix IDS 参数和监控 Informix IDS 运行效率，来提高数据库的性能。
虚拟处理器参数的调整和监控
Informix IDS 对于虚拟处理器的分类，达到了十多种，每个虚拟处理器像操作系统的一个 CPU 允许多个进程服务于多个用户一样，也可以运行多个线程来为多个 SQL 客户机应用程序提供服务。其中最重要的虚拟处理器是 CPU、AIO、网络处理器三种，在这三种服务器中，CPU 虚拟处理器（CPU VP）是最重要的，它驱动其他虚拟处理器，如磁盘 I/O 虚拟处理器（AIO VP）和 IDS 会话中的所有线程。AIO VP 的功能是在 SQL 语句访问或更新数据库数据时，执行磁盘 I/O。网络处理器涉及到数据库服务器的客户机或用户连接。可以进行两种类型的连接：共享内存连接和网络连接。下面分别介绍这三种类型的参数。
1．CPU 虚拟处理器（CPU VP）的参数
NUMCPUVPS：定义了 Informix IDS 开始启动的 CPU VP 的数量。一般情况下不能超过系统 CPU 的个数，对于单或双 CPU 的计算机系统，建议设置 NUMCPUVPS 是 1 或者 2，即使用一个或两个 CPU VP；对于有 4 个以上 CPU，建议设置 NUMCPUVPS 的值等于处理器总数减1。
SINGLE_CPU_VP：定义了多 CPU VP（0）和单 CPU VP（1）设置。
MULTIPROCESSOR：定义了多个 CPU VP（1）还是单个 CPU VP（0）。
AFF_NPROCS：定义了可以绑定到 CPU VP 的 CPU 的数目。
AFF_SPROC：定义了把连续的几个 CPU（AFF_NRPOCS 参数定义的值）中第一个 CPU 的序号连接到 CPU VP 上。
例如，某个 Informix IDS 系统所在的硬件平台有 4 个 CPU，AFF_NPROCS 设置为 3（即可用于绑定CPUVP的CPU 有 3 个），NUMCPUVPS 设置为 3， AFF_SPROC 设置为 1，则 3 个 CPUVP 需要绑定到 CPU 上，是从第 2 个 CPU 开始，绑定到第二、三、四个 CPU 上。SINGLE_CPU_VP 设置为 0。
2．对于磁盘 I/O 虚拟处理器（AIO VP）的配置
NUMAIOVP 指定系统上 AIO/KAIO 虚拟处理器的数目，如果 Informix IDS 采用裸设备存储，可以设置成2。
在 Informix IDS9.2 以后的版本中将 NUMCPUVPS、NOAGE、AFF_NPROCS、AFF_SPROC、NUMAIOVP 用VPCLASS 参数代替。当 Informix IDS 处于 online 的状态下，可以使用 onmode -p (+/-)# 来增加或者减少虚拟处理器。#代表增加或者减少虚拟处理器的个数。
3．对于网络处理器参数的配置
NETTYPE：定义了Informix IDS 的连接类型和连接可以连接的轮询线索数目。如果 sqlhosts 文件中支持一个以上的接口或协议的连接，就必须对每个连接类型规定独立的 NETTYPE 参数。
轮询线索可以在两类VP上运行：NET VP和 CPUVP。为得到最佳性能，Informix 建议使用 NETTYPE 表项为CPU VP类只分配一个轮询线索，将其余轮询线索轮询线索分配给 NET VP。分配给任何一种连接类型的轮询线索不得超过 NUMCPUVPS 的取值。
NETTYPE 的配置格式如下：NETTYPE connection_type，poll_threads，c_per_t，vp_class 。其中，connection_type 标识轮询线索分配的连接协议；poll_threads 是分配给该连接类型的轮询线索数目，对任何连接类型，这个值不能超过 NUMCPUVPS 值；c_per_t 是每个轮询线索的连接数目，可以用如下公式计算这个值：c_per_t=connections/poll_threads；connections 是所希望指定的连接类型支持的最大连接数。对于共享内存连接（ipcshm），该值应该加倍以获得最好的性能；vp_class 是可运行轮询线索的 VP 类，如果 CPU VP 上只运行一个轮询线索，那么指定为C PU VP。
在对虚拟处理器的监控中，可以通过系统的一些命令，也可以通过数据库的一些命令，常用的数据库命令是 onstat-grea 和 onstat -g ioq。
以下是 onstat -g rea 的输出：
/usr/informix >onstat -g rea
Informix Dynamic Server Version 9.30.FC5 -- On-Line -- Up 36 days 00:22:32 -
- 5352416 Kbytes
Ready threads:
tid tcb rstcb prty status vp-class name
onstat -g rea 监控了就绪队列中的线程数目。包括准备运行而且在等待资源的线程。理想的状态下是输出极少的条目或者不显示任何条目。如果输出的某种 VP 类条目持续增长，那么就要考虑在该类中添加 VP。
在 onstat-g iog 指令的输出中，最需要关注的列是 len 列。len 列的值应该总是为 0 或接近于 0。如果该列的值很高并持续增长，那么我们可能需要添加另一个 AIO/KAIO 虚拟处理器来减少磁盘 I/O 负载。
监控虚拟处理器的方法比较多，可以使用 Informix IDS 查询语句在系统表中找到虚拟处理器的使用情况:还可以在 Unix 操作系统中使用系统命令 sar、top 等来监控操作系统的 CPU 使用情况；还可以在一段时间内的重复执行 Informix IDS 命令 onstat-g glo 来监控各个虚拟处理器已占用的 CPU 资源。判断 CPU 的忙闲。
内存使用效率的参数调整和监控
Informix IDS 使用的内存部分被数据库服务器线程以及其他用户和虚拟进程共享，所以这部分的内存叫做共享内存，共享内存减少磁盘 I/O, 提供了最快地进行进程间通信的方法，还可以使数据库服务器减少总的内存使用。
Informix IDS 共享内存分为四个部分：驻留部分、虚处理部分、消息部分和虚拟扩展区部分，其中消息部分只有在客户机和服务器采用共享内存方式连接时才有，而且尺寸很小。虚拟扩展区也极小，它包含了用于 DataBlade 模块的线程 heaps 和其他在用户定义的虚拟处理器中运行的用户定义例程。
1．驻留内存部分的参数
驻留内存部分又可以细分为：共享内存头、缓冲区，逻辑日志缓冲区、物理日志缓冲区、锁。
共享内存头在共享内存中包含所有其他结构的描述，还包含到这些结构位置的指针共享内存头是在初始化 Informix IDS 时创建的，并且不能进行调优。
缓冲区存储 Informix IDS 从 dbspace 所读取的数据，是数据库对象数据，如表的数据或索引数据。缓冲区占用了驻留内存中最大的部分。所有的缓冲区被组织到一个较长的最近最少使用（least- recently-used，LRU）缓冲区队列中，并通过最近最少使用（LRU）机制进行管理。定义缓冲区的参数是 BUFFERS。称作指定共享内存缓冲区的最大数目，该参数对数据库 I/O 和事务处理吞吐量有明显的影响。但是，如果分配过多的缓冲区会影响到操作系统的内存并导致过多的交换内存页面的活动。一般建议设置为物理内存的 20% 到20%。
逻辑日志缓冲区是用来存储最后一次备份开始的逻辑日志记录的。逻辑日志记录保存了 SQL 语句对数据库数据进行的修改。在初始化 Informix IDS 时，它创建三个逻辑日志缓冲区，以循环方式运作，来确保将获得的每一条逻辑日志记录都被刷新到磁盘中。LOGBUFF 定义了逻辑日志缓冲区的数量，缓冲区的大小决定了它被添满的频率，从而决定了它必须被刷新到硬盘上的逻辑文件中的频率。一般情况下，Informix IDS 建议设置为 16KB 或 32KB
物理日志缓冲区在 Informix IDS 修改或着删除记录之前，将该记录的原始值存入到物理日志缓冲区中，在事务失败时，用于恢复数据，以保持数据的一致性。在 Informix IDS 初始化时，创建了两个物理日志缓冲区，也以循环的方式运作。与物理日志缓冲区对应的参数是 PHYSBUFF。
锁包含可用锁的数量，每个用户对数据库的连接并执行数据库的操作，都需要一定数量的锁。在 Informix IDS9.2 以后的版本中，当用户的锁不够时，可以动态的分配锁的数量。在以前的版本中，该数值是固定不变的。与锁对应的参数是 LOCKS。一般情况下设置为 2000 到 8000000 个。
2．共享内存虚拟存储区的参数
共享内存虚拟存储区存储各种各样的不同数据，可以分为：内部表、较大的缓冲区、会话数据、线程数据（堆栈和堆）、数据分布缓存器、字典缓存器、SPL 例程缓存器、SQL 语句缓存器、排序池、全局池。
影响虚拟存储区的参数是：SHMADD、SHMVIRTSIZE 、STACKSIZE。
SHMVIRTSIZE 定义了分配 Informix IDS 共享内存的虚拟存储区的大小。Informix IDS 在处理大型查询或高峰负荷的需要增加共享内存给虚拟存储区，但是共享内存的分配需要增加事务处理的时间，故在设置SHMVIRTSIZE 值时，一般考虑能满足一个日常操作的需要。
STACKSIZE 指示了数据库服务器为每个活动线程指派的初始堆栈的大小。如果将该参数配置得过小，那么线程将无法拥有执行其程序的足够内存空间，而且它将干扰其他线程。
SHMADD 定义了 Informix IDS 自动加到虚拟存储区的共享内存增量的大小。在增加共享内存时，要占用CPU 周期；每次的增加量越大，增加次数就越少，留给其它的进程的内存也越少。所以一般采用大的增加量。但是在内存负荷很重时，少量增加使其他程序更好的共享内存资源。所以，如果实际内存小于等于 256MB，则建议 SHMADD 使用缺省值 8192KB；如果在 256MB 到 512MB 之间，则设置为 16384KB;如果大于 512MB，则设置为32768KB。
可以用命令 onstat -g seg 来显示 IDS 当前共享内存虚拟区中的段的数目。
Informix IDS 在初始化时，如果定义的虚拟内存区尺寸太小，会自动向虚拟区附加其他操作系统段，虚拟内存中的段过多从而引起数据库的整体性能下降。所以在初始化时，将虚拟内存区的尺寸配置得足够大，以避免进行动态的分配共享内存段。在该列的输出中，class 列为 R 是驻留内存段，V 是虚拟内存段，M是消息内存段。如果显示的虚拟内存段多于三个，那么就需要提高配置文件中 SHMVERSIZE 参数的值。
命令 onstat -p 是监控内存的另一个命令。其输出结果中的两个 %cache 显示了读写高速缓存比例的百分比，一般在 80% 到 90%之间，如果低于80%，要调节 BUFFERS 参数值。ovlock 字段表明 IDS 在使用了最大数量的锁之后尝试过再使用锁的次数，如果该数字非零，可能需要提高配置文件中 LOCKS 参数的值。ovbuf 字段表明 IDS 在使用了最大数量的缓冲区之后尝试过再使用缓冲区的次数。如果该数字很大，比如说超过 100000，就需要提高 BUFFERS 参数，以便用户在需要从磁盘访问数据时不必等待缓冲区。在监控内存的使用情况时还可以采用 Unix 系统命令 vmstat。
存储器及 I/O 的参数调整和监控
Informix IDS 支持两种基本的数据存储设备裸设备和文件系统，建议使用裸设备存储数据文件。与文件系统相比，裸设备在存取数据时要快得多，而且对用户来说是看不到裸设备文件的，要安全一些。使用文件系统作为数据存储设备还有一个潜在的危险，当文件系统由于某些操作系统的错误而崩溃，且有一个数据库事务正在进行时，数据库服务器将认为数据库事务已经成功完成，但实际上，该事务正陷入操作系统缓冲区中，这最终将导致数据库中的某些不一致。
Informix IDS 在 dbspace 中存取数据，dbspace又包含一个或多个 chunk（块）。在 9.40 以后的版本中chunk的大小可以超过 2G，在以前的版本中不能超过2G。可以使用 onsta－d 监控 dbspace 和 chunk 的使用情况和状态。
与 I/O 参数调整直接相关的是检查点。检查点是使磁盘上的页与共享内存缓冲池中的页同步的过程。检查点时间包含检查点间隔时间和检查点持续时间。在检查点期间，IDS 阻止用户线程进入临界会话，并阻止所有的事务活动。因此，检查点持续时间过长，用户会经历系统挂起。
CKPTINTVL 参数指定检查点之间的时间间隔。当检查点间隔到了，则系统执行检查点操作。
PHYSFILE 指定物理日志的大小。一旦物理日志（PHYSFILE）的75%已满，检查点也会发生。
LRUS 参数指示共享内存缓冲池中设置的最近最少使用（LRU）队列数目。
可以用 LRUS 和 LRU_MAX_DIRTY 及 LRU_MIN_DIRTY 来控制在满的检查点之间页被刷新到磁盘的频度。在某些情况下，通过设置这些参数，使得在检查点发生时需要刷新修改的页数量很少，可以达到高的吞吐量；假如检查点持续时间始终超过 10 秒甚至以上，那么可能需要减少 LRU_MIN_DIRTY 和 LRU_MAX_DIRTY 配置参数的值以获取更短的检查点持续时间。可以使用 onstat -R 和 onstat -P、onstat -F 命令的输出来确定参数值的大小。一般情况下 LRU_MIN_DIRTY 设置为 50，LRU_MAX_DIRTY 设置为 70。
调整 Informix IDS 参数来优化数据库性能，是 Informix IDS 性能优化的一个方面，它的性能调优还要从网络、硬件、操作系统、应用程序等多个方面来综合考虑，其性能的优化是一个高度复杂，异常繁琐而且涉及面很广的综合性工作，而且它们之间相互关联，相互影响。在调整过程中，应该明确数据库的运行状况和系统资源的使用情况，确定问题的瓶颈出现在哪里。然后根据问题的所在来优化数据库的性能。数据库参数的调整是数据库优化的一个方面，在此只是想起到一个抛砖引玉的作用。
1160
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
