Informix 高级培训教材

1. ONLINE5 与ONLINE7 的比较
1.1. 系统体系结构的差别
ONLINE5 的内部处理结构是一对一的单线索的结构，每个用户对应一个数据库服务器进程，数据库服务器进程负责响应客户的数据请求，而数据库内部的协调处理由ONLINE 守护进程负责，数据库服务器进程和ONLINE 守护进程间相互独立。
ONLINE7 采用的是先进的多线索的体系结构，多线索结构是核核心层的，客户应用进程和数据库服务器进程（VP）之间是多对多的关系，即一个 客户应用进程可以有多个数据库服务器进程服务，反之，一个数据库服务器进程也可以为多个客户应用进程服务。
ONLINE7 的优点是：充分利用CPU 的并发处理能力，而且数据库服务器进程的数目不是随着用户进程的增加而增加，减轻了系统的负荷。
ONLINE5 中，客户应用进程和数据库服务器进程之间的通信是通过UNIX 管道实现的，数据库服务器进程间通讯是通过共享内存完成的。如果 通过网络连接必须使用INformIX-STAR 这个产品。而ONLINE7 集成了INformIX-STAR,户应用和服务器之间的通讯即可以是共 享内存方式也可以通过TCP/IP 的SOCKET 或TLI 实现，同时还支持了IPX/SPX 协议。 e[Q$J
1.2. 系统性能的差别 S
ONLINE5 不能在联机方式下改变共享内存的大小和数据库服务器的个数，而ONLINE7 可以在联机的方式增加共享内存和增加虚拟处理器的个数，这样就达到了系统的动态可伸缩的特性。
ONLINE7 因使用了多线索体系结构，一个查询可以使用多个线索，因此很好的支持了并行查询的功能(PDQ)。ONLINE7 还增加了对数据分割的支持。
1.3. 系统可靠性的差别
ONLINE7 增加了数据复制的功能（CDR）。
ONLINE7 在数据备份和恢复功能都有所增强，备份可以并行创建。只要rootdbs没有损坏，任何一个chunk 的损坏不影响整个ONLINE 的运行。ONLINE 启动时的快速恢复功能也使用多线索并行处理。
Informix 高级培训教材(内部) []A4H
5 ?91Talk论坛 -- 张扬你的个性，IT技术、时尚、娱乐.. 就要自由，就要ＴＡＬＫ！ n3DSlkz
1.4. 命令的差别
ONLINE5 的命令都以tb 开头如：tbinit, tbmode,tbstat, tbtape
ONLINE7 的命令都以on 开头如：oninit, onmode,onstat, ontape
另外，在ONLINE 配置方面ONLINE7 多了许多参数，这部分在ONLINE 配置部分介绍。
2. ONLINE7 的配置及性能调整
这部分讨论的是INformIX ONLINE 数据库服务器的性能监测和调整。性能监测和调整的研究和实践是很广泛的。这里只讨论 ONLINE 数据库管理的日常维护的问题和方法。人们一直在讨论如何提高数据库的性能，数据如何存储、如何读取、如何配置参数才使你的应用得到更好的性 能。例如：当要优化一个系统时，为一个有1000 用户并都执行短小简单的事物的系统，和为一个只有很少用户但执行很长且复杂的事物的系统的参数配置是完 全不一样的。我们从以下几个方面阐述：
2 监控系统资源并评价系统的性能
2 数据库活动对系统性能评价的影响
2 用online 提供的工具来监控和调整系统性能
2 从以下几方面消除系统性能的瓶颈：
1． 平衡系统资源的负载
2． 调整online 的参数
3． 调整数据的布局
4． 为关键查询分配资源
适当平衡系统负载往往可以改善系统性能。有时性能改善是变化的，且往往使用单一的负载均衡的方法不能完全满足要求，下面从更广的范围对此进行讨论：
1． 修改应用程序，以便其能更好的利用操作系统和数据库的资源
2． 系统性能没有被充分利用
3． 网络的性能影响了C/S 结构的应用性能
2.1. 确定系统性能的目标确定系统性能目标时考虑的问题：
1． 要获得最大的交易吞吐量，还是最快的响应时间，或者是两者的混合。
2． 网络对性能的影响
3． 希望的最大用户数
4． 你的配置是否受内存、磁盘和CPU 资源的限制Informix 高级培训教材(内部)

2.2. 系统性能监测和调整的基本方法
系统的性能是否好是个模糊的概念，不太容易说清楚，比如用户会说有时系统很慢，有时一个交易不知道为什么不能完成等等，这就需要透过表面现象分析系统性能 问题的真正瓶颈。我们建议通过反复多次的评价、调整的方法来接近您所要求的性能目标。如果反复的经过下面提供的步骤的调整都无法满足您对性能的要求，则很 可能是您的硬件资源受到限制，或应用程序编码不当引起的问题。
ONLINE性能优化步骤
1. 确定您的性能目标.
2. 获得资源利用率和数据库活动的数据
3. 确定性能问题的症状：不均衡的CPU、内存和磁盘的利用率。
4. 调整操作系统的参数。
5. 调整ONLINE的参数。
6. 优化chunk 和dbspace 的配置, 包括日志、排序空间、临时表和排序文件的存放位置。
7. 优化表的存放位置、extent大小和分段处理。
8. 改善索引.
9. 优化后台I/O活动,包括logging, check-points,和page cleaning.
10. 规划备份和批处理业务的时间
11. 优化数据库应用的执行。
12. 重复2-11 部。
2.3. 影响性能的配置参数
影响性能的参数包括操作系统的参数和ONLINE 的参数。在进行参数调整前应该对当前参数的性能进行评估。一般改变操作系统参数需要重新启动机器，改变ONLINE 的参数需要重新启动ONLINE。
2.3.1. 影响性能的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 / 100MAX_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 个区分别是：
2 驻留内存区：这部分时静态的，在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 要支持）。
2 虚拟内存区：这部分时动态增长的，但在初始化是也应分配个适当的值。它是由以下几部分组成的：
用于大的读写操作的大缓冲区
排序池
活动线程控制块、栈、堆
用户对话数据
数据字典高速缓存和存储过程
用于网络接口信息的全局池
初始的区大小由SHMVIRTSIZE 参数决定，增加的区大小由SHMADD 参数决定。
根据一般经验，每个用户要占100K~500K 的虚拟内存区的空间，如果用了数据分割应该再加 4M 。可以用onstat -g mem 命令共享内存区的大小
2 消息内存区：这部分是静态的，在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