多方面的参数设置对Informix性能的影响

 出处：Unix爱好者家园unix-cd.com   

应使用原始磁盘空间，不要使用文件系统空间。

原始磁盘空间意味着通过一个字符模式特殊文件（在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与DSS

OLTP的特点：

用户多

高事务率

在数据处理方面，事务相对较小

明显的页操作（插入/更新/删除）

通过索引的快速数据访问

高度使用缓冲区快速缓存

并行范围有限


DSS特点

涉及大量数据

很少的写操作（除临时空间和数据加载之外）

用户相对较少

处理大批数据的大量、复杂查询

主要通过顺序扫描访问数据

并行范围广


磁盘分布与分片

磁盘硬件的选项：

传输速度高，定位时间少

大量的小盘比少量的大盘好

避免控制器过载


将Online磁盘空间与其它系统操作分开

文件系统

交换空间

将物理、逻辑日志分开

对于有大量的写操作（插入、更新、删除）的任何Online应用环境应将逻辑和物理日志分别放在不同的磁盘/控制器上。在放置物理、逻辑日志的磁盘上不要再放其它数据。

将逻辑日志放在不同的磁盘上

避免当前日志于各份日志之间出现冲突

减少磁头移动

如果可能的话，控制原始分区的分配以减少磁头的移动

控制表分割

尽量防止表分为多个段（extent),这对OnLine 5.0及以前的各版十分重要。

避免过多的chunk

即使没有dirty页，大量的chunk也会明显增加检查点的时间。

明智地使用数据分片

不要对小表进行分片

不要对所有的表进行分片

确定数据量大且频繁访问重要表

将表的每个分片放在单独的磁盘上

使用轮转（round robin)方式分割索引要小心

OLTP--轮询方式分割数据，分离（也可分割）索引

通常为使OLTP性能最佳，要考虑用轮询方式将使用高的大表分割到不同磁盘的DBSPACE中（为分散多个磁盘间I/O)。这些表的索引也应明确地生成在特定的dbspace上（与数据不同的磁盘上)。也可以按表达式进行分片。

DSS--轮转或基于表达式方式分割数据，无索引或尽量少

通常为使DSS性能最佳，考虑哪种方式分割大表最好，是轮询还是表达式方式，对不同的表使用不同的分片方式，其目标是为了平衡总体I/O，并可以使优化器对频繁运行的查询消除对不必要分片的扫描

基于表达式方式分片

表达式应该简洁。对给定的dbspace，首先使用最有约束力的、限制条件最多的表达式：

例如使用x<=10 and x>=1 in dbspace1,而不要使用x>=1 and x<=10 in dbspace1。

将访问频度高的 dbspace放在访问频度低的dbspace前

避免使用进行类型转换的表达式

不要按经常改换值得列进行分片

在分片间进行的移动要付出额外的开销

仔细选择表达式

为了均衡I/O负载，而不是数据量

为了帮助消除查询中无需扫描的段

避免使用REMAINDER IN子句

使用多个数据库临时空间（DBSPACETEMP)

如果DBSPACETEMP列出多个dbspace的话，将大大并行涉及临时空间的操作。如使用多个临时dbspace，将它们放在与其它活动频繁的dbspace不同、且彼此分开的磁盘上。


OPTCOMPIND

OLTP--设置为0

对OLTP，应避免使用散列（hash)连接，因为该连接方式将大量消耗处理器资源。

DSS--设置为2

对DSS，散列连接可以提供很好的连接性能。


LRUS

最少4，否则等于NUMCPUVPS


缓冲区

对OLTP而言，需要较大的缓冲区池和较高的缓存命中率

对典型的OLTP工作负载，当大量访问在系统的缓存中的页时可以获得最好的性能，为了实现这点需要有大小合适的缓存区。通过onstat -p可以显示出缓存的效率，它将显示读、写的快速缓存命中百分率。在可用内存的限制下，要尽可能地提高该数字，通常获得95％以上的读命中率和85以上的写命中率是可能的。

对DSS而言，通常一个较小的缓冲区就够了

对典型的DSS工作负载，多数数据访问是有light scan扫描完成的，而不通过缓冲池，造成不需要使用大量缓冲池的后果。内存应由DS_TOTAL_MEMORY分配，以便有足够的内存用于扫描缓冲区，散列连接等。


Bufferd Logging 与UnBuffered Logging

Bufferd Logging 比UnBuffered Logging性能好

使用Buffered Logging,逻辑日志缓冲区只在充满时才向磁盘刷新。使用UnBuffered Logging,每次事务提交都会强制一次日志缓冲区刷新。注意由于逻辑日志缓冲区对所有的数据库是公用的，所以即使仅有一个活动频繁的数据库使用非缓冲日志也会大大降低使用缓冲日志带来的益处。

Buffered Logging 不如 UnBufferd Logging安全

由于日志缓冲区充满时才进行刷新，如果系统出现故障，则日志缓冲区的内容会被丢失。当然发生故障时，缓冲区会良好保存未写向磁盘的提交记录，Online快速恢复将回滚这些事务。所有数据库自身保持一致，而从应用程序的观点看，应用程序认为已经成功提交的事务实际上却回滚了，这是不一致的。


CKPTINTVL参数

正常操作期间，两个主要的事件会导致检查点发生：超过检查点时间间隔或是物理日志75％已充满。在检查点间的工作量决定了系统故障后快速恢复所需要的时间长短。

如果恢复时间十分重要，则应设置检查点间隔以使恢复时间可以接受，否则可以加长时间间隔，从而让系统根据物理日志充满度（75％）来决定何时生成检查点。


连接

客户机－－－－数据库服务器和数据库服务器－－－－客户机

选择最佳的通讯机制 本地客户机：共享内存和管道

对于与服务器运行在同一主机上的客户机，应选择共享内存（ipcshm)或管道（ipcstr)方式。管道通常要比共享内存方式更快、更灵活、更安全、避免让本地客户使用网络连接（TCP/IP)，因为那样比ipcshm或ipcstr连接性能要大大降低。

远端客户机：TCP/IP

远端客户要使用TCP/IP,只有在特殊情况下才使用Netware IPX/SPX进行连接。改变缓冲区大小（FET_BUF_SIZE环境变量）以及socket缓冲区大小（在sqlhosts文件中设置）观察其效果。使用前面叙述的方法减少客户机/服务器间的交换量。

轮询线索和网络VP

轮询线索处理从客户机送来的数据

从服务器到客户机的数据是由各自的sqlexec线索来发送的。

一个轮询线索可以处理大约200个典型客户机

数目要依许多因素而定，此处只是个原则数字。

对大量非常活跃的客户，或大量的数据输入可能需要更多的轮询线索。

轮询线索在CPU虚处理器（内联轮询）（inline poll)或NET VP中。

任意时刻，只有一个“内联”的协议


内联轮询线索

客户数目越少，性能越好

可以帮助TCP/IP

增加CPU VP额外开支

不可有多于CPU VP数目的轮询线索


用于轮询线索的NET VP

对大量的客户而言，可能会提供更好的性能

想要多少就可以有多少轮询线索

可减轻CPU VP的工作负荷


监视会话

可以用onstat 及SMI监视会话

应检查有问题的会话过程

线索的数目

磁盘I/O

内存的使用情况

SQL语句


SINGLE_CPU_VP标志

让系统消除一些互斥操作

如只使用一个CPU虚处理器，并确信不需要再动态增加，一定要设置ONCONFIG文件中的SINGLE_CPU_VP标志为ON。这样可以让Online 消除许多用于内部CPU VP同步的互斥调用。


监视OnLine性能

onstat 

命令行工具，显示系统操作不同方面的有关信息

SMI

是通过SQL接口的输出与onstat 相近的信息，它可以开发用户的监视工具。

Onperf/Xtree

基于图形（X/Motif)的性能监视工具，可以运行在许多平台上，可以显示OnLine服务器的查询树。

Oncheck

检查表，索引的完整性等等。