有关Informix数据库的性能问题
现在有一IBM p550的小型机其硬件配置如下：Processor Type: PowerPC_POWER5
Number Of Processors: 4
Processor Clock Speed: 2097 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
LPAR Info: 1 06-40C5H
Memory Size: 11840 MB
Good Memory Size: 11840 M
该机器是4路双核的CPU
原来安装Informix（10.0 UC4)的参数非常保守（该数据库是由客户的科技人员安装的），LOCK NUMBER只有10万，BUFFER POOL只有5万，而且并没有启用多处理器方式。在没有调整参数之前，BUFFER读的缓存命中率只有85%左右，写的命中率就更低在80%左右徘徊，而且死锁频繁出现。现将LOCK NUMBER调整到了100万，BUFFER POOL调整到了20万，同时启用了多处理器方式，Num Procs to Affinity设为了2，CPU VPs 和 AIO VPs各为1，目前BUFFER读的缓存命中率达到了99%左右，写的命中率达到了88%，死锁基本没有了，但是lockreqs增长很快，lokwaits也增长的较快。按理来说该机器配置不算低，但是在运行一个对数据库进行批处理操作的应用时比同类型机器要慢很多，希望大家帮忙找找还有哪些因素影响了该机器的性能。
BTW，该机器只运行Informix数据库，没有其他数据库以及web server之类的大型应用 数据库的性能优化主要靠配置onconfig文件实现，给个参考标准，希望对楼主有所帮助
注：因为标准繁多，在实现中只列出各项的值，不作规则判断，并将onconfig文件内容打包传回，供巡检人员参考
rootdbs >100M
phydbs >100M
logdbs >300M,物理日志空间与逻辑日志空间的大小之比为 1:3 。
tempdbs >500M, 必须设置成临时数据空间属性。
TAPEDEV /dev/rmt/0m
LTAPEDEV 对于冷双机一般配置为/dev/null 的文件；
HDR方式一般是/opt/informix/log.dat(可以其它文件名，不用管)
Log.dat 是联接到/dev/null的一个空文件。
LOCKS 设置建议：400000 每个LOCK占44bytes的内存，根据系统内存情况酌情增减
BUFFERS 100000
BUFFERS是以页为单位，通常1页=2k或者4K
大小一般为内存大小的1/4，如果大于200M，则配置200M， 最多不能大于300M。
SHMVIRTSIZE 30000
在物理内存较大，业务量较大时，可以设置得更大一些。
LRUS 设置建议：32
影响Informix数据库磁盘写性能：LRUS越大checkpoint时间越短，各应用进程包括ninit进程系统占用时间越少。
LRU_MAX_DIRTY 2
LRU_MIN_DIRTY 1
其大小与系统性能体现密切相关，直接关系到Informix数据库写命中率，其值越大写命中率越大系统性能体现越好，但checkpoint时间同时成比例急剧上升。
设置建议：
与系统磁盘IO性能相关，可以通过checkpoint时间进行判定，如果checkpoint时间在2秒以内可设置成2/1，如果checkpoint时间在3秒左右可以考虑减少 BUFFERS。
CLEANERS 8
与Informix数据库磁盘写性能有一定的关系，与数据库 checkpoint时间相关，CLEANERS太小checkpoint时间很长，但大于一定数值后相关性减少。磁盘个数和数据库空间数目越多CLEANERS要求配置较大些，CLEANERS太大会稍稍降低系统性能。
设置建议：
informix的dbspace所使用的物理磁盘个数小于4个设置为8，小于8个设置为12，大于8个设置为16。
OPTCOMPIND 建议配置为0
单、 双CPU配置项设置
对于双CPU系统，配置成多CPU方式、及CPU绑定，对系统性能没有改观，特别是CPU绑定设置相反影响系统性能。
设置建议：
MUTIPROCESSOR：1具体配置与CPU数目和机型相关,见下文表格描述和注意事项
NUMCPUVPS：1
SINGLE_CPU_VP：1
CPU个数 MUTIPROCESSOR NUMCPUVPS SINGLE_CPU_VP
1 0 1 1
2 0 1 1
3-7 1 nrOfCPUs-1 0
>7 1 nrOfCPUs*0.7 0
注：1) MULTIPROCESSOR在AIX4.3上要固定配置为0
2) 在AIX 5.3(Power5+)系统上，CPU为双核，此时上面表格中的cpu个数以OS看到的逻辑cpu为准。
Caizhiwei modiefied
NOAGE 设置建议：1
1表示进程优先级不会随着时间而降低。
CKPINTVL 3600
正常操作期间，两个主要的事件会导致检查点发生：超过检查点时间间隔或是物理日志75％已充满。在检查点间的工作量决定了系统故障后快速恢复所需要的时间长短。如果恢复时间十分重要，则应设置检查点间隔以使恢复时间可以接受，否则可以加长时间间隔，从而让系统根据物理日志充满度（75％）来决定何时生成检查点。
设置建议：3600。
DBSPACETEMP tempdbs
配置多个tempdbs时，以冒号隔开。（标准为冒号，逗号也可用）
DUMPDIR /opt/informix/temp
配置原则是该文件系统必须有足够的可用空间，大于500M，
建议使用 /opt/informix/temp。
若此temp目录在/opt/informix下不存在，请在相应路径下以informix用户手工创建，并修改该目录的读写属性，命令如下：
$chmod a+rw temp
STACKSIZE 128
默认为32K，一般够用，如果系统会执行嵌套较多的sql或者存储过程，
设置太小可能导致DBMS系统栈溢出
回复 #1 wingofwind 的帖子
ding,学习中！！！！！！ 并发问题，有些应用考虑使用脏读，如果是IDS11还可以设置read last committed。lock可以继续方法，20万TPCC的机器，LOCK才40万少点。
另外你4个CPU怎么能CPU VP才设置成1啊？
问题找到了
原来该数据库在dbimport的时候，没有对几个百万记录级的表进行优化，导致我在使用EXPLAIN的时候发现语句的过滤条件都在索引上时，仍然使用SEQUENTIAL SCAN。由于相信对方在导库之后已经作了更新，一直没有考虑这一点，结果被误导了，极其郁闷。这一点希望大家引起重视，在出现这种情况时不要被表已建索引的现象误导，最好使用SET EXPLAIN将查询的路径显示出来，以便分析。对大记录级别的表必须要优化器统计信息。如果性能还提高不大的话，可以考虑重建索引后再更新统计信息。
页:
[1]