影响性能的配置参数
影响性能的CPU 参数
1．操作系统的参数：
1．信号量(SEMMNS )
SEMMNS = init_vps + added_vps + (2 * shmem_users)+concurrent_utils
2．同时打开文件数(NFILES)
NFILES = (chunks * NUMAIOVPS) + NUMCPUVPS + net_connections
2．ONLINE的相关参数：
NUMCPUVPS：初始分配的CPU VPs的个数，在单处理器的主机中此值建议用1，再多处理器的主机中此值不应大于物理CPU的个数，建议使用比物理处理器少1。此值可以通过onmode -p命令动态增加。
CPU VPs的个数将决定在一个查询中扫描线索（Scan Threads）的个数。当扫描线索数的整数倍时查询会获得最好的性能。onstat -g ath命令监控每个CPU VP的扫描线索数，onstat -g ses命令监控某个具体会话。
SINGLE_CPU_VP：当CPU VPs值等于1时，此值也设置为1，否则为1。当此值为1时，NUMCPUVPS必须设置为1,否则ONLINE会报错。
MULTIPROCESSOR：当CPU VPs值大于1时，此值也设置为1，否则为0。
NOAGE：为ONLINE CPU VP设置关闭处理器优先级老化的开关（需要OS支持），1为关闭。AFF_NPROCS：CPU绑定功能，就是可以通过CPU绑定来为处理器分配不同的任务。绑定几个CPU。
AFF_SPROC：从第几个CPU开始绑。
NUMAIOVPS：说明使用几个AIO VPs。如果OS不支持核心异步IO (KAIO)的话，ONLINE使用AIO管理所有数据库I/O请求。AIO Vps的个数依赖于你配置了多少磁盘。如果系统不支持KAIO的话，建议为每个chunk分配一个AIO VPS。还有一个分配AIO VPs的标准是看I/O请求队列的长度是否足够短。onstat -g ioq 命令可以监控待AIO VPs 处理的I/O请求队列的长度。
尽量多的分配AIO VPs是不会对系统有何副作用，可以通过onmde -p动态增加AIO的个数，但不能动态的减少。
OPTCOMPIND：该参数帮助优化器为应用选择一个最适合的存取方式。如果该值为0，优化器首先选择已存在的索引既是顺序扫描速度更快。当该值为0，并且隔离级别设置为重复读模式，优化器适用嵌套循环连接的方式。当该值为2（缺省），优化器选择基于消耗评估的连接方法，即使表扫描引起整个表被临时锁住。用户可以通过设置环境变量改变该值。
MAX_PDQPRIORITY：该值限制一个查询可以占用的PDQ资源的百分比。
DS_MAX_QUERIES：描述同事的最大决策支持查询的个数。ONLINE通过该值和DS_TOTAL_MEMORY: 决定为一个查询分配多少内存。
DS_MAX_SCANS：该值限制了PDQ的扫描线索的个数。该值避免PDQ引起的扫描线索被过度使用。
分配给一个查询的扫描线索数是通过下面的公式计算的：
scan_threads = min (nfrags, (DS_MAX_SCANS * pdqpriority / 100*MAX_PDQPRIORITY / 100) )
减少扫描线索数可以提高几个大查询同时运行时的响应。
NETTYPE：为每个连接类型配置轮训线索。一般情况每个DBSERVER 对应一个连接类型。轮训线索可以定义两种类型VP: CPU 和NET。建议只使用一个CPU 类型的轮训线索，其它的给NET 类型的轮训线索，总的轮训线索数不能大于努NUMCPUVPS。尽管训线索理论上可以支持1024 个连接，但单CPU 主机每个轮训线索支持300 个连接比较好，而多CPU 主机每个轮训线索支持350 个连接比较好。该值为定义缺省是一个CPU 轮训线索，每个轮训线索支持50 个连接。适当的增加轮训线索可以提高性能。注：ipcshm 方式的连接是需要占用信号量资源的。
onstat -g glo
当前运行的各个虚拟处理器(VP)已占用的CPU 资源。可以通过间隔1 分钟时间两次执行该命令， 将两次结果9 相减，如果结果接近60 秒说明CPU 很忙。
onstat -g rea
监控等待运行的线索，如果列出线索较多说明CPU 处理能力不足。可以考虑增加CPU VP 的个数。
2.3.2. 影响性能的内存参数
这部分讨论影响性能的内存参数，包括OS 和ONLINE 的参数配置，你必须考虑如何均衡的使用有限的内存资源。
当OS 分配一块共享内存是我们把它叫做段（segment）, ONLINE 在用这块共享内存段时我们又把它叫做区（portion）。ONLINE 根据需要把共享内存分成了3 个区分别是：
² 驻留内存区：这部分时静态的，在ONLINE 初始化时分配。它是由以下几个参数组成的：
BUFFERS：通过下面的公式可以计算出buffer所占内存
buffer_value = (BUFFERS * pagesize) + (BUFFERS * 254)
LOCKS：通过下面的公式可以计算出LOCK所占内存
locks_value = LOCKS * 44
LOGBUFF：通过下面的公式可以计算出逻辑日志buffer所占内存
logbuff_value = LOGBUFF * 1024 * 3
PHYSBUFF：通过下面的公式可以计算出物理日志buffer 所占内存
physbuff_value = PHYSBUFF * 1024 * 2
驻留内存区的大小是按下面的公式计算的：
rsegsize = (buffer_value + locks_value + logbuff_value+ cphysbuff_value + 51,200) / 1024
另外， RESIDENT 设为1 时这部分被强制驻留物理内存而不会被换出（ OS 要支持）。
² 虚拟内存区：这部分时动态增长的，但在初始化是也应分配个适当的值。它是由以下几部分组成的：
用于大的读写操作的大缓冲区
排序池
活动线程控制块、栈、堆
用户对话数据
数据字典高速缓存和存储过程
用于网络接口信息的全局池
初始的区大小由SHMVIRTSIZE 参数决定，增加的区大小由SHMADD 参数决定。
根据一般经验，每个用户要占100K~500K 的虚拟内存区的空间，如果用了数据分割应该再加4M。可以用onstat -g mem 命令共享内存区的大小
² 消息内存区：这部分是静态的，在ONLINE 初始化时分配。它包括共享内存通讯接口的消息缓冲区。它的大小依赖与你允许的连接用户数。它的大小可由下面的公式计算出Informix
msegsize = (10,531 * ipcshm_conn + 50,000)/1024
与内存有关的ONLINE 参数
SHMVIRTSIZE：决定虚拟内存区的初始区大小。当虚拟内存区不够用时ONLINE会自动增加一个新的区，但这会消耗ONLINE的处理资源。因此，该值应该尽可能的，一般先下面两种情况中大的一种：
8，000 或connection* 350
SHMADD：决定ONLINE动态增加的虚拟内存区的大小。虚拟内存区的增加会消耗CPU的资源。它也应尽可能的大，但当内存方生很多的换出的情况，就应减少了。建议按下表进行设置
===========================================
Memory Size SHMADD value
256 megabytes or less 8,192 kilobytes (the default)
Between 257 and 512 megabytes 16,384 kilobytes
Larger than 512 megabytes 32,768 kilobytes
===========================================
可以用onstat -g seg 命令监控ONLINE共享内存区的使用情况。
SHMTOTAL：限制ONLINE最多使用的共享内存的大小。如果是0，根据实际情况动态增加，除非有特殊情况，如大量内存被换出，一般都设置为0。
BUFFERS：设置ONLINE使用的数据缓冲区的多少。该部分是驻留内存区，用户数据在内存中的高速缓冲。更多的BUFFER可以带来更多的曾经访问过的数据驻留在内存中。该值对数据库I/O和交易吞吐量都是非常重要的。但过多的分配BUFFER也会造成内存资源的浪费而影响其他部分对内存的使用。建议BUFFER占用的内存是实际内存的20%~25%之间。用onstat -p 命令看读写cache的大小，如果过低应该增加该值。 配置原则是物理内存的20%~30%。在系统没用页交换发生的情况下，尽量多的增加buffer。用onstat -p 命令察看读Cached 在95%以上，写Cached在85%以上说明BUFFERS 值较合理，同时结合vmstat 命令观察交换区的使用情况。
LOCKS: 如果onstat -p 中lockwaits 值较大应适当增加locks 数。有个有用的命令: onmode -F 方法系统空闲的内存，并可以将该命令加到系统的crontab 中定期执行。
RESIDENT: 确定驻留内存区是否被被强制驻留在物理内存中，而不会被换出（OS 要支持）。驻留内存区还包括可LRU 对列，LRU 与数据库的读写操作有关。该值建议设为1，如OS 不支持将报错并被忽略。
STACKSIZE: 确定为每个线程分配多少栈空间。该部分空间是在虚拟内存区中分配的。用如下公式计算总的栈大小:
stacktotal = STACKSIZE * avg_no_of_threads
LOCKS：确定同时可以打开的最大的锁的数目。绝对最大值是8M，每个LOCK占用44字节（在驻留区）。可以通过下图来评估一条SQL语句可能占用锁的个数：
LOGBUFF：确定逻辑日志的缓冲区的空间大小。它的大小决定了逻辑日志被刷新的磁盘上的频度。
PHYSBUFF：确定物理日志的缓冲区的空间大小。它的大小决定了物理日志被刷新的磁盘上的频度。
DS_TOTAL_MEMORY： 确定一个查询最多可获得的共享内存百分比。一般，在一个OLTP 系统中该值为：20%~50%之间。如果是一个DDS 系统中该值为：50%~80% 之间，甚至90% 。当该值未赋则ONLINE 按如下公式计算:
min_ds_total_memory = NUMCPUVPS * 2 * 128Kb
2.3.3. 影响性能的I/O 的参数
CHUNK 和DBSPACES 的配置
在整个I/O 过程中磁盘是最为缓慢的一个环节，因此如何安排好磁盘空间的使用也使I/O 性能的关键。
在创建CHUNK 时建议将一个完整的分区分配个CHUNK，避免offset 计算错误引起的数据访问失败。
在５．0 以前的版本建议一个DBSPACES 使用都个CHUNK 来提高性能，但从7.0 以后对此不在要求，反而是最好一个DBSPACES 用一个CHUNK，这样便于作数据分割。
ONLINE 在缺省情况将临时表建在rootdbs 中，建议使用DBSPACETEMP 参数建立temp dbspace, 用于临时表的存放。
设置预读的参数
RA_PAGES: 确定ONLINE预读的页数，
RA_THRESHOLD：ONLINE 响应I/O 请求的指针
用下面的计算公式：
RA_PAGES = (BUFFERS * bp_fract) / (2 * large_queries) + 2
RA_THRESHOLD = (BUFFERS * bp_fract) / (2 * large_queries) - 2
配置后台I/O
后台I/O 不能直接服务于SQL 请求。后台I/O 主要是维护数据一致性。后台I/O带来高速的I/O 同时消耗CPU 资源,同时会与交易竞争系统资源。如果后台I/O 过多会影响应用的性能。下面是一些后台I/O:
Checkpoints
Logging
Page cleaning
Backup and restore
Rollback and recovery
Data replication
Checkpoints、Logging、Page cleaning 是数据库维护数据一致性所必需的后台I/O。相对后台I/O，前台I/O 的效率比较差，因此尽量避免前台I/O。可以通过增加Page Cleaning数或减少触发Page Cleaning 来减少前台I/O。用onstat -F 命令可以监控前台I/O 的频率。
影响后台I/O 的参数
CKPTINTVL：设置checkpoint的时间间隔，onstat -m可以监控checkpoint的时间。当物理日志达到75%时也发生checkpoint，
LOGSIZE
LOGSIZE
LOGFILES
LOGSMAX
PHYSFILE
PHYSFILE
影响日志的参数
LOGBUFF
PHYSBUFF
LTXHWM
LTXEHWM
影响Page Cleaning 的参数
CLEANERS：清页线索的个数，建议每个磁盘使用一个清页线索。
LRUS 有更多的LRU就会有更多的Page Cleaning,用onstat -R命令监控脏页的比例
LRU_MAX_DIRTY：LRU的最大脏读比例
LRU_MIN_DIRTY：LRU的最小脏读比例
RA_PAGES 6
RA_THRESHOLD 三种写的比较
1． 前台写：由sqlexec 亲自刷新，前台写效率最低尽量避免。
2． LRU 写：它是由LRU_MAX_DIRTY 和LRU_MIN_DIRTY 决定刷新的频率，并且这种刷新操作是不彻底的，但有个好处是在刷新时不会终止用户线索的操作。
3． Chunk 写：这种写实最彻底并且效率最高，但在写的时候所有用户线索不能进入临界区，因此检查点会延迟用户的响应时间。
通过onstat -F 可以观察以上三种写的使用情况。可以通过改变LRU_MAX_DIRTY 和LRU_MIN_DIRTY 及CKPTINTVL 的值调整写的方式。