Tuning Informix Engine Parameters V1.7
http://home.earthlink.net/~mildness/bamph/informix.htm
stanlee 回复于：2003-04-09 12:16:47
很好! 正需要这东东!
不过还有好好研究，结合工作实际。
davidma 回复于：2003-04-10 10:14:17
:?
有没有中文的？
lanbird 回复于：2003-04-10 12:49:48
提议:
那位英文好的大虾给简单翻译一份贴出来,
informix 组的弟兄们会很感激你的.
chenjiakai 回复于：2003-04-11 01:54:14
Informix 引擎参数调整
一、简介：
对于引擎的调整是我日常的爱好，不论是内燃机引擎还是数据库引擎。
很少有数据库在调整后性能不能提升20%的。对于一个组织良好的调整小组来说，使性能得到巨大提升 并非难事。这并不是因为我的特异功能，而是因为系统很快就处于失调状态或者根本就没有调整过。
以下是我近年来收集的一些对于informix引擎配置参数设置的一些建议。我将他们保存在我的效率手册中以便随时查阅。
我收集了许多关于数据库调整的书。但是我对于他们大多数都不敢苟同。原因主要有以下几项：
⑴ 系统底层结构的变化，使得许多建议值迅速过时。
⑵ 不同的UNIX对于调整来说也有极大的不同。
⑶ 硬件发展的速度远远超过我们所能知道的程度。
对于上述的第一点，可以用informix 7 的一个早起版本证明。informix引擎的磁盘I/O子系统发生了巨大变化，以至于之前所有的NUMAIOVPS的建议值都是错的。
Unix进程管理的具体实现是上述第二点的一个很好的例子。我在 Menlo Park Informix基准实验室中进行的一系列测试表明，在HP/UNIX平台上，配置实际CPU数量两倍的CPUVPS是最适宜的。而在我们测试的那个版本的solaris系统中，则首选使用建议的1:1的比例配置。
我最喜欢用的关于这些冲突的例子在INFORMIX-OnLine Dynamic Server Performance Tuning Training Manual（2/97)一书中的6-134页。当谈及在不使用核心I/O的系统中配置 NUMAIOVPS时，书中提到参考控制器的数量以1:1的比例配置，而在后来的第三行中又说每个磁盘一个。
注意这三个例子说的是可调参数中的两个具有很大可变性并因此可争议的参数。读者应该从中得出三个重要的结论：
⑴ 用绝对的措词来描述这种事情是危险的。
⑵ 每一个重要的终端用户的环境都要进行单独衡量和调整，这就是说，一刀切的做法将会给数据库系统管理员带来麻烦。
⑶ 更重要的是，由于这些最基础的知识的不固定，必须善待数据库管理员。
接下来是我收集的每个onconfig 参数的笔记。许多直接来源于书本。一些评论和蓝色斜体字是出自我的经验。在有多个建议列出的时候，我按照时间顺序排列，时间早的先出现。
我们假定参加测试的机器是一台专用的数据库服务器，informix必须被看做是自己的操作系统，他向UNIX请求的仅仅是CPU的时间片。如果他不得不与其他的应用程序，其他的数据库引擎，甚至另一个informix实例共享sandbox，他就超出了涉及目标。
好费劲，英文水平太差了先翻到这，请大家指教。
对于最后一段好像不是太懂，不知道各位高手有何见解。大家共同讨论。
qiuf 回复于：2003-04-11 11:47:44
lol：说了这么长就没一点到正题
lanbird 回复于：2003-04-11 12:20:26
chenjiakai 老兄， 辛苦，辛苦！
INTRODUCTION 部分译的不错。
楼上大哥你行的话你继续往下译啊！不要在这里打击别人积极性。
qiuf 回复于：2003-04-11 12:38:37
我不是说楼上翻译的不好，我说的是老外的文章内容空泛，不要误会
chenjiakai 回复于：2003-04-13 00:31:18
其实我的英文水平也就仅此而已，翻译这么一点就花了好长时间。关于这篇文章，我倒不觉得前面这段空泛，之所以译它还就是因为这段文字写得挺好的。我们很多时候在做Performance Tuning时，都是参照书上说的一些方法，在自己的机器上试，认为这样就ok了，实际上不是这样的，应该有一点实践精神，敢于怀疑书上说的东西。很多关于Performance Tuning的书上讲的都是一些经典的方法，都是Informix提供的一些标准建议值，很少有人探讨一些真正适用于实践的方法，自己得出适合于自己系统的参数配置值。后面的我觉得都不用翻译了，都是一些说明性的简单的东西。我想只要大家玩过informix都可以看懂的。
蓝色键盘 回复于：2003-04-14 10:28:21
严重同意楼上的说法！！！！
qiuf 回复于：2003-04-14 15:23:27
正如老外文章提到的，稍有头脑的技术人员都应该知道每一份参数配置对不同的机器所能达到的优化效果是不同的。但是如何做？为何要这么做？这些才是我们需要深入了解的，而这些'简单的东西'又有谁来告诉我呢？我想大多数技术人员更需要的是里面的内容译文吧
大梦 回复于：2003-04-14 15:41:49
谁行谁继续！
为大家做点好事！
kofchen 回复于：2003-04-14 20:02:34
我支持chenjiakai大哥！！！！
顶顶
大梦 回复于：2003-04-14 20:16:56
chenjiakai 是好样的，向他致敬！
forest077 回复于：2003-04-17 08:53:08
引用：原帖由 "chenjiakai"]其实我的英文水平也就仅此而已，翻译这么一点就花了好长时间。关于这篇文章，我倒不觉得前面这段空泛，之所以译它还就是因为这段文字写得挺好的。我们很多时候在做Performance Tuning时，都是参照书上说的一些方法，..........
发表：
你是南京大学的吗？名字好熟。
pillow 回复于：2003-04-17 10:04:12
chenjiakai 是英雄！！！
应该受勋！！！
嘉奖！！！
请他吃饭！！！
cruelsun 回复于：2003-04-17 15:17:52
引用：原帖由 "chenjiakai"]我在 Menlo Park Informix基准实验室中进行的一系列测试表明，在HP/UNIX平台上，配置实际CPU数量两倍的CPUVPS是最适宜的。而在我们测试的那个版本的solaris系统中，则首选使用建议的1:1的比例配置。.........
发表：
很想知道他是基于什么样的测试。
unixjack 回复于：2003-08-08 20:13:31
有英文的就不错了，谢谢你。
l_yqh 回复于：2003-08-14 21:11:20
我看到这篇文章，觉得很好，就想翻译了，前面的chenjiakai翻译了，我从后面开始。
因为对informix不太了解，翻译的很不好，有一些不知道怎么翻译的就放上了原文，希望哪个高手帮忙整理一下，就可以把我翻译的删了。
我尽量争取在一周内把剩下的也翻译完。
MAIN
ROOTSIZE
Logical Logs + [Phys logs] + [Temp Tables] + [Data] + [On-Arc.catalogs] + crtl info (res. pages)
这是最小磁盘空间的计算公式，对于重要的系统logical units应该放在独立的磁盘上。
SERVERNUM
CPU上的每个引擎对应一个。
CPU USAGE
RESIDENT
如果informix 安装在专门的服务器上面，把该参数打开。如果不支持该参数会被忽略；
在混合环境中打开该参数，会导致informix和它的客户端程序配合不正常。
NUMCPUVPS * ?/b>;
如果#HWCPUs >; 3，则设为#HWCPUs - 1
#scan thrds (frag issue) SB a multiple or factor of NUMCPUVPS determine w/ glo ath rea.
一般data loading = #HWCPUs，如果使用HPL, 则为 HWCPUs – CONVERTVPS (onpload config param)
我看到过有的系统VCPUS ：HW CPUs为1:1运行的非常好，有的系统则在比例为2:1:1的情况下运行的更好。
MULTIPROCESSOR
SINGLECPU
Both of these turn on different housekeeping mechanics，
如果NUMCPUVPS 设为1，两个参数必须都turn off或者分别为0和1，这是非常重要的。除非
两个参数都设为turn off，否则配置1个CPUVP不会有任何好处，这一点常常被忽视。
我建议两个参数当做一个考虑，如果一个调整了，另一个也必须做相应的调整。
NOAGE ?/b>;
如果支持该参数就设为1，关闭Unix nicing 。 Nicing是unix确保在混合环境中让所有程序平等获取cpu时间的一种机制，它通过降低一些程序的优先级实现。当Informix运行在一台独立的服务器上时，应该打开该参数。
在混合环境中优化该参数不象黑和白那么简单。最好一开始关闭，在以后希望informix占用更多的cpu时间再把它打开。
AFF_SPROC ?/b>;
开始绑定的CPU数. mpstat会提供CPUs的数目和相关的数据。 This numbering system seems whimsical.
AFF_NPROCS ?/b>;
要绑定的HWCPUs。
NUMCPUVPS = HW CPUs – AFF_SPROC
这对于不是专门用作数据库服务器的系统非常有好处。
其它非informix进程可以允许运行在这里指明的HW CPUs，但CPUVPS 只能运行在这里指明的HW CPUs。
USEOSTIME
0 internal timer 更快。我没有见过使用OS timing 的。
注意：
-g glo （onstat的参数）显示的用户和系统CPUVPS比例应该是10:1，对于KAIO这个比例可能是3:1，如果在只有很少的HW CPUs系统中，系统CPUVPS占的比例太高，尽量只使用1个CPUVPS.
-g rea 如果显示大于等于7个线程在等待，增加CPUVPS会导致informix当机.
unix commands：
mpstat
sar
uptime
是非常实用的工具，负荷平均要结合系统资源的了解情况。I have seen slow systems with a la of 2 and I have seen systems that seemed find at double digits.
对于一台计算机只在相对早期的检查系统资源时有用。
l_yqh 回复于：2003-08-19 20:49:51
DISK IO
BUFFERS* (pages)
OLTP调优的关键参数；
开始启动时20% RAM，可以增加到50% RAM，在一台专用的数据库服务器上，完全可以达到50%
增加BUFFERS的大小到cache hits最大或者超过系统页面数，使用sar或vmstat帮助决定页面大小。
OLTP目标 95% 读, 85% 写 cache hits
对于DSS，buffers小于最大的表，会强制使用light scans。使用 –g lsc检查light scans
最大化data loading (50% 或更多) (除了 HPL express mode)
更多的buffers意味着更长时间的checkpoints
NUMAIOVPS* – 对这一条的建议好像随着天气在变化，意思是变得很快
对于ea，1/(每个数据库磁盘 + 1) 。 数据空间的读取很频繁。
If KAIO is used allocate 1 + 2 for each cooked chunk (get rid of any cooked chunks) 如果使用KAIO，分配1＋2*cooked chunk数（消除所有的cooked chunks）
对于KAIO系统，OnLine分配 2，然后每个controller以及 cooked chunks分配1
对于系统w/o KAIO，OnLine分配2，每个controller分配1，then add as indicated.
1 per dbspace
1 per disk
1 per mirrored pair
1 per chunk.
‘-g ioq’ to monitor IO Qs
DSA spawns one read thread per dbspace (AIO or KAIO)
我的意见是建立一套支持KAIO的系统，把该值设为2.
RA_PAGES
大部分的计算机限制在30, 最多不能超过32.
Dig: 对于不执行light scan的系统，RA_PAGES值不要超过32.
对于典型的顺序DSS（决策支持系统）要高点；
如果太高会降低%缓冲区读；
如果bufwaits不同寻常的高，可能RA_PAGES太高了，或者RA_PAGES和RA_THRESHOLD之间的差太小。
RA_THRESHOLD
设置成接近RA_PAGES，例如RA_PAGES 32 and RA_THRESHOLD 30。如果bufwaits (-p) 增加了，减小RA_THRESHOLD值。 If most machines limit at 30 won’t the RA_THRESHOLD remain in a constant TRUE state?
理想的使用的RA-pgs = (ixda-RA + idx-RA + da-RA)
DBSPACETEMP*
对于每个不同的驱动器至少是2，如果要创建大量的索引要更多点。
DSS 环境应使用HW，通过多磁盘得到少量的TEMPDBS。
创建索引所需要的最大空间计算方法：: non-fragmented tbls (key_size+4) * num_recs *2, fragmented (key_size+8) * num_recs *2
FILLFACTOR (indices)
一般为90, 如果该表只有select/delete操作为100（只进行delete最后没有数了怎么办？）
最初强制紧凑的索引和有效的缓存。
50-70% for tbls with high INSERTS to delay need for node splitting
MIRROR
总是mirror.
几年前，测试安装在USENET的informix时，人们每次都使用HW mirroring。 This make sense as who will have a more intimate knowledge of the devices? HW 的方案总是比SW的快。因此，我偏向于建议大家使用HW, OS and then Informix mirroring.
因为机器是很容易获得的，因此，你可以通过控制器甚至阵列实现mirror。
IOSTATS
该参数在文档中没有，如果设为1，会产生SMI系统管理信息表读写的时间。
看附录C 关于 DSA Performance Tuning Training Manual
TBLSPACE_STATS
New
NOTES:
增加AIO processes的优先级， 可以提高磁盘返回数据的性能。
使用-g ioq (也可以使用iof 和 iov)检查IO. 当 AIOs 配置参数 gfd len SB < 10, maxlen <25. Maxlen often breaks 25 during engine initialization when it is unimportant so make this distinction. –D will show hotspots at disk level –g ppf at partition level.
在为我现在的老板创建一个很重要的数据库时，the Sun Hotshot 建议对于4GB的磁盘，使用中间2GB的扇区存放数据, 其它空间保留。 这个报酬很高的informix项目是个典型例子，我在这里非常明显的感觉到如果仅使用前面2GB扇区，性能要更好。 后来我建议我们做个测试，如果在 5% 以内可以决定这么做，因为这样易于维护。结果证明前面的扇区比中间扇区有 2% 的性能提升。I do not recall which I ended up implementing.
如果你的系统要IO bound 校验，或者是控制器，或者是disk bound，解决方案是不同的。
Throughput = (pg_size * num_pgs_requested/max_transfer_rate) + latency
使用聚集索引会极大的增加sequential reads的时间。
Informix 建议尽可能使用fragmentation over HW striping，我希望有时间检验一下该论点。
我一直没有能测试出Kernal IO如何影响NUMCPUVPS 的配置。在DSA Performance Tuning Manual (2-97)中写到： "如果你的系统支持kernal aio, onstat –g ath will show one kio thread per CPUVP." 因此是否 NUMCPUVPS 和磁盘数或者和硬件CPUs数相关?
UNIX COMMANDS:
iostat
sar
vmstat
l_yqh 回复于：2003-08-22 16:52:02
LOGGING
CLEANERS*
1 per disk if < 20 disks
1 per 2 disks if 20 to 100
4 per disk if >; 100
UPDATE at least one per LRU queue pair. This has most recently been best for me.
If –f indicates that all cleaners are active allocate more.
PHYSDBS
! rootdbs. Place on a separate spindle
PHYSFILE
= usrthreads * 5 (or size of most freq. blob) * 4
PHYSBUFF
= usrthrds * 5 * 4
UNLESS tblspace blobs in DB w/o logging then usrthrds * size of freq blob pg * 4
LOGFILES
>; 3
在所有的手册中，对这个参数的调整我没有看到很好的参考，除了消除一些反常的现象以外，我也没有很好的经验。
LOGSIZE
>; 200kb
small for greatest recovery, if tape slow, or blobpages volatile
(connects * maxrows (in one trans)) * 512
LOGBUFF
size of 3 LL buffers in RAM
取决于刷新到磁盘的频率。
LOGSMAX
LOGFILES + 3
CKPTINTVL
adjust interval of checkpoints, see LRU.
For data loading (except HPL express mode) and parallel index builds 3000
如果checkpoint间隔很大，则由physlog的大小决定什么时候checkpoint。
–F 会显示写盘操作是 LRU 驱动还是 CHKPTINTVL 驱动
–l and –m 会显示checkpoint 间隔是由 Physlog = 75% full决定还是由这个参数决定
LRUS*
max(4, NUMCPUVPS)
if -R 表明#dirty pages >; LRU_MAX + LRU Qs. 如果没有变化，增加 CLEANERS
UPDATE: 4 per CPUVP (this relationship has most recently been best for me.)
1 per 500-750 buffers, up to 128 (max)
更多的 LRUs 可通过减少buggwaits来更好的支持大量用户的访问。
–g spi 显示单个LRU队列的 contention
LRU_MAX[MIN]_DIRTY - %buffers assigned to modified queue
值变小可以缩短checkpoint的间隔。
对于 data loading (except HPL express mode) & 并行创建索引， 70 & 80%, 在刷新间隔内，这样的比例可以满足要求，队列接近最大长度。allow to almost fill before flushing
Monitor: –R queue length, -F writes forced by this parameter by CLEANER thread
LTAPEDEV
Set to /dev/null，Informix将不会输出logical log，这样设置的前提是系统不需要logical log恢复的作用而且用户知道这样设置会带来的后果。
LTXHWM
50
LTXEHWM
60
LBU_PRESERVE - Preserve last log for log backup
注意:
如果physlog频繁的被写满，需要减少checkpoint间隔（CKPINTVL）
phys logging - buffsize/pages IO SB >;75%, 如果接近100%，需要增加 physbuff size
physical and logical log buffers 合理的空间大小应当是当刷新时，已经使用的空间占整个分配空间的75% 。
Huge bang for the buck makes Checkpoints another early thing to look at.
salaciouswolf 回复于：2003-08-25 20:29:31
强！向高手致敬（不管是informix高手还是e文高手！）
l_yqh 回复于：2003-09-02 10:22:50
终于翻译完了。请大家参考原文看吧，如果翻译的不对，请大家指出来。
BLOBS/OPTICAL
STAGEBLOB (Optical)
OPCACHEMAX
0
NETWORK
NETTYPE
1 if CPU, 其它的poll threads分配给NETVPs
单个HWCPU为300， 如果更多的话为350
对于data loading， 1/CPUVP。 each poll thread should be on a CPU class VPS (running a poll thread in-line)
不要增加用户连接，因为这样会导致需要增加对 poll thread 的工作
UNIX COMMANDS:
netstat
SESSION
LOCKS
最大值： 任何查询需要消耗的锁的数量 * 并发用户数
OPTCOMPIND
MEMORY
SHMBASE
SHMVIRTSIZE* (kilobytes)
OLTP - 大缓存, 小的虚拟内存 (SHMVIRTSIZE)
DSS - 小缓存, 大的虚拟内存
DSS may be up to 75% RAM if paging is not induced
DSS KEY FIELD
SHMADD (kilobytes) -
10 - 20% of SHMVIRTSIZE
SHMTOTAL ?/b>;
0 没有限制
这个参数可以设置的很小，这样informix占用的资源很少，其它的应用程序就可以多占用一点，这么做也使得informix表现的更加礼貌的，：）。
不过有时候，oninit（informix启动分配memory）失败了，我会不得不修改这个参数。
Monitoring: -g seg – 这是我会首先检查的几个参数之一，因为增加shared memory segments 是一件吃力不讨好的事情，（shared memory的增加对性能不会有很好的提高，而且使其它应用程序的可用memory减少）
注意： that onmode -F (用来释放 memory segments) 会导致正在运行的系统 failures，因此应该避免这样的情况。
UNIX COMMANDS:
Sar -g 3 3 – will show paging activity
Vmstat
Notes:
To calc shared memory segments corresponding to a DB instance shmid – 52564801*.0001 = SERVERNUM
DSS PARAMETERS
PDQPRIORITY
if >; 0, 将增强索引创建的并行处理能力，(7.2之后，在某种程度上，索引创建都是并行的)
MAX_PDQPRIORITY
100
DS_MAX_QUERIES
DS_TOTAL_MEMORY
DSS should be 90% of SHMVIRTSIZE
DS_MAX_SCANS
1048576
Notes:
Quantum = (PDQPRIORITY/100)*(DS_TOTAL_MEMORY/DS_MAX_QUERIES)
每个排序线程都要计算 quantum/排序线程的内存空间
A users effective priority = (pdqpriority/100) * ( MAX_PDQPRIORITY/100) 这里 pdqpriority 通过环境变量设置或者SET PDQPRIORITY 设置
DEBUGGING/RECOVERY
OFF_RECVRY_THREADS
10
ON_RECVRY_THREADS
1
DUMPDIR
DUMPSHMEM
0 我发现许多系统失败的原因是由于 Informix往临时目录/tmp中写了很多东西，默认应该是off.
DUMPGCORE
0
DUMPCORE
0
DUMPCNT
1
DATASKIP
off
ONDBSPACEDOWN
0
DATA REPLICATION
DRAUTO
0
DRINTERVAL
30
DRTIMEOUT
30
DRLOSTFOUND
/usr/informix/etc/dr.lostfound
MISC NOTES
Oncheck –pr 可以用来恢复丢失的 onconfig 文件
Resident – Buffer Pool (Pool is for residents use only - I needed a mnemonic for this.)
Virtual – Light Scan Area (事实上不记日志 - this too.)
Storage overhead
对于数据库来说，每个数据页使用28 个字节。
对于每一行是4 个字节的slot entry（我想slot entry可以翻译成入口，或索引，即对于每行记录，有四个字节记录它的位置，通过这四个字节可以找到这一行记录）
在7.2中，对索引创建的查询和排序总是并行处理的， Idx builds on fragmented tables add parallel B-(sub)tree builders
UPDATE STATISTICS – 对 Q perf.， 最常用的SQL 语句，收集统计信息，使得查询时，数据库引擎可以最优的查询算法。
HIGH
lead columns in each index
all columns queried with equality filters (=)
all join columns
1st col to uniquely distinguish a composite idx from another on same table and all cols preceding
MEDIUM
all other columns
LOW
all idx cols. Not run through on HIGH
要加快update statistics 设置 PSORT_NPROCS 为 2, use DBSPACETEMP (duh) do NOT set DBUPSPACE (limits RAM for US)
下面的步骤来自于一本经典的著作。 我不记得原来作者的名字了.
informix数据库性能优化步骤：
1、设立性能优化的目标。
2、测量数据库的运行状况和资源的使用情况。
3、明确性能问题的瓶颈在哪里？比如 CPU, memory, or disks等.
4、调整操作系统.
5、调整 Online Dynamic Server
6、优化日志、分类空间和临时空间的存放位置。
7、优化表空间的存放，sizes of extents, and fragmentation
8、确认索引的创建是合适的.
9、优化后台的活动，比如：logging, checkpoints, and page cleaning.
10、在空闲的时段定时运行备份工作和其它批量运行的工作。
11、重新阅读应用程序，确认获取数据的方法是合适的，算法是有效的。
12、重复步骤 2 到 11.
我附加几点：
1、.5 and 2.5 明确用户的预期结果。（.5指在1步骤之前。2.5指在2和3之间）
2、步骤3 & 4 找一个有丰富经验的系统管理员来帮忙。
3、步骤11 可以进行的更早和更频繁些，因为最大的性能提高来自应用程序的调整。
4、投入一定的时间完全沉浸在这个工作中，至少要3天。如果在开发环境中，在整个项目开发从开始到结束，确保有两周的时间专注于这项工作。在工作中常常不得已减少这个时间，但3天是最少的，否则不足以彻底的完成这个工作。
5、针对一个具体的表，计算最大的 extents :
Max#extents <= (pagesize – ((4 * number of columns in a table) + (8 * number of BLOB and VARCHAR columns + 136) + (12 * number of indices) + (4 * number of columns in the indices) + 84))
Loading Hints:
周期性的整理大表的数据存放碎片。
找出最频繁访问的表:
SELECT t.tabname table, p.pf_dskreads + p.pf_dskwrites totalops,p.pf_dskreads diskreads , p.pf_dskwrites diskwrites
FROM sysptntab p, systabnames t
WHERE t.partnum = p.partnum
ORDER BY totalops DESC
参考书目：
INFORMIX-OnLine Dynamic Server Performance Tuning Training Manual - Informix part number 502-5-403-1-9999999-1 - Liz Suto, Course Designer
Tuning Informix Dynamic Server and Your System for Optimum Performance - Art S. Kagel
More to come...
Please forward any comments to mildness@earthlink.net
|
