logo资料库

informix IDS 健康检查.doc

第1页 / 共14页
第2页 / 共14页
第3页 / 共14页
第4页 / 共14页
第5页 / 共14页
第6页 / 共14页
第7页 / 共14页
第8页 / 共14页
资料共14页,剩余部分请下载后查看
1。共享内存检查
1.1 共享内存的配置
1.2 BUFFER读写的缓冲率
1.3 物理日志BUFFER和逻辑日志 BUFFER
2. 磁盘IO
2.1 checkpoint duration
2.2 checkpoint 的IO效率
2.3 IO 热点检查
2.4 chunk 写(ckpt)和 LRU 写的平衡
2.5 是否使用kaio
2.6 表碎片检测
3. CPU 使用
3.1 IDS 的 CPU平均使用率 VS 系统CPU使用率
3.2 CLEANERS 的设置
3.3 定位消耗 CPU 资源多的 table 或 index
4.对 online.log 的解读
4.1 IDS异常down的记录
4.2 af文件的查找和分析
4.3 数据库表和index的损坏记录
4.4 ckpt duration 记录
4.5 最大连接数的变化
4.6 逻辑日志填充的速度(log_count/day)
4.7 其他异常的告警
informix IDS 健康检查概述 目录 1。共享内存检查.............................................................................................................................. 2 1.1 共享内存的配置............................................................................................................... 2 1.2 BUFFER 读写的缓冲率 ......................................................................................................2 1.3 物理日志 BUFFER 和逻辑日志 BUFFER ...................................................................... 3 2. 磁盘 IO.......................................................................................................................................... 4 2.1 checkpoint duration........................................................................................................... 4 2.2 checkpoint 的 IO 效率 ..................................................................................................... 5 2.3 IO 热点检查 .....................................................................................................................5 2.4 chunk 写和 LRU 写的平衡 .............................................................................................. 6 2.5 是否使用 kaio..................................................................................................................... 7 2.6 表碎片检测......................................................................................................................... 7 3. CPU 使用 .......................................................................................................................................9 3.1 IDS 的 CPU 平均使用率 VS 系统 CPU 使用率.........................................................9 3.2 CLEANERS 的设置....................................................................................................... 10 3.3 定位消耗 CPU 资源多的 table 或 index.................................................................... 11 4.对 online.log 的解读 ................................................................................................................12 IDS 异常 down 的记录...................................................................................................12 4.1 4.2 af 文件的查找和分析.....................................................................................................13 4.3 数据库表和 index 的损坏记录........................................................................................13 4.4 ckpt duration 记录..........................................................................................................13 4.5 最大连接数的变化 ...........................................................................................................13 4.6 逻辑日志填充的速度(log_count/day) ............................................................................. 14 4.7 其他异常的告警............................................................................................................... 14 1
INFORMIX IDS 实例由共享内存、磁盘空间和 CPU 进程三大部分组成,对 INFORMIX IDS 的健康检查就是对这三个组成部分的配置和使用情况的指标进行检查和评估,并对 online.log 中记录的异常信息进行及时的分析和处理。 1。共享内存检查 1.1 共享内存的配置 概述: IDS 的共享内存由驻留部分(R)、虚拟部分(V)和消息部分(M)组成,对 OLTP 系 统,一般 R 部分是最大的部分,V 段的数量一般不超过 3 个;M 部分可有可无,共享内存 的总量一般占物理内存的 1/3 到 4/5。 监控命令: onstat -g seg 输出示例: IBM Informix Dynamic Server Version 9.40.FC8 Segment Summary: id 4096 4097 3 4 Total: key 1381386241 10a000000 1381386242 209000000 1381386243 27d600000 1381386244 29d200000 - size 4278190080 1952448512 532676608 532676608 7295991808 addr - -- On-Line -- Up 100 days 13:52:22 -- 7124992 Kbytes ovhd 553352 60240 16912 16912 - class blkused blkfree 1044480 0 R V 452884 12797 V 4470 V - 1514631 23788 117251 125578 266617 主要参数: BUFFERPOOL 或 BUFFERS SHMVIRTSIZE SHMADD # initial virtual shared memory segment size # Size of new shared memory segments (Kbytes) 1.2 BUFFER 读写的缓冲率 概述: BUFFER 读写缓冲率是判断 BUFFER 分配是否合理的重要指标,一般要求:读缓冲率 大于 95%,写缓冲率大于 85%;一般加大 BUFFERS 可提高读缓冲率 监控命令: 2
onstat –p start read write rewrite delete commit rollbk pagwrits bufwrits %cached pagreads bufreads %cached dskwrits 12129440131 29729555567 71826322755 89.83 -- On-Line -- Up 100 days 13:52:21 -- 7124992 Kbytes 输出示例: IBM Informix Dynamic Server Version 9.40.FC8 Profile dskreads 50697174601 64090039104 4457842935778 98.87 isamtot open 1901643192403 911138137 182863641919 1146239089186 25955172308 2020778955 2757142472 61796389 676035 gp_read gp_write gp_rewrt gp_del 0 0 ovlock usercpu syscpu 1168017 0 bufwaits lokwaits lockreqs deadlks 815098371 135432 ixda-RA idx-RA da-RA 6442812322 135047031 15463594620 21809819864 2840121945 gp_alloc gp_free 0 numckpts flushes 25137234.62 1990665.77 28949 dltouts 544330011213 1931 0 0 ovuserthread ovbuff ckpwaits compress seqscans 174659 547948078 1934375986 RA-pgsused lchwaits gp_curs 0 57898 0 0 29 主要参数 BUFFERS 或 BUFFERPOOL 1.3 物理日志 BUFFER 和逻辑日志 BUFFER 概述: 物理日志 BUFFER 和逻辑日志 BUFFER 用于对物理日志和逻辑日志文件的读写缓冲, 每个 IDS 实例有 2 个物理日志 BUFFER 和 3 个逻辑日志 BUFFER。一般物理日志 BUFFER 和逻辑日志 BUFFER 使用率在 75%时是合理的;如果使用率低/高时,可通过调小/大对应 BUFFER 的大小来达到合适的 BUFFER 使用率。 监控命令: onstat –l 输出示例: IBM Informix Dynamic Server Version 9.40.FC8 Physical Logging Buffer bufused numpages numwrits pages/io bufsize 128 -- On-Line -- Up 100 days 13:52:29 -- 7124992 Kbytes P-2 53 phybegin 2:53 1080498635 9599534 112.56 phyused 90848 phypos 930877 physize 950000 %used 9.56 Logical Logging Buffer bufused L-3 105 bufsize 128 numrecs numpages numwrits recs/pages pages/io 18396097459 1757100288 29819369 10.5 58.9 Subsystem numrecs Log Space used 3
OLDRSAM address 24c96cfb0 。。。。。。 number 7 18396097459 3521979990540 begin flags U-B---- uniqid 116007 11:53 size 100000 used 100000 %used 100.00 相关参数: PHYSBUFF 256 256 LOGBUFF 2. 磁盘 IO # Physical log buffer size (Kbytes) # Logical log buffer size (Kbytes) 2.1 checkpoint duration 概述: checkpoint duration 是判断 IDS IO 效率的主要指标,在 OLTP 系统中一般应小于 3 秒, 如果 checkpoint duration 持续较高(> 10 秒),可能存在存储的 IO 效率或写操作过多,或 配置参数不合理; 监控命令: onstat –m,或直接查看 online.log 文件 输出示例: 5:08:04 Fuzzy Checkpoint Completed: 15:08:04 Checkpoint loguniq 113963, logpos 0x8675428, timestamp: 0xe32d9ba7 duration was 0 seconds, 837 buffers not flushed. 15:08:04 Maximum server connections 1059 15:13:14 Fuzzy Checkpoint Completed: 15:13:14 Checkpoint loguniq 113963, logpos 0x10b970f0, timestamp: 0xe34d05ea duration was 9 seconds, 833 buffers not flushed. 15:13:14 Maximum server connections 1059 15:15:49 Logical Log 113963 Complete, timestamp: 0xe35feecc. 15:18:18 Fuzzy Checkpoint Completed: 15:18:18 Checkpoint loguniq 113964, logpos 0xe56b5b4, timestamp: 0xe38de4e8 duration was 3 seconds, 4 buffers not flushed. 15:18:18 Maximum server connections 1059 相关参数: Checkpointerval:检查点间隔; LRU_MAX_DIRTY; LRU_MIN_DIRTY;控制检查点间隔内脏页的比例; PHYSFILE 物理日志文件大小,在前映像达到75%启动检查点; LRUS:影响写的效率; 4
cleaner;影响写的效率… 2.2 checkpoint 的 IO 效率 概述: checkpoint IO 效率是判断 IDS 存储 IO 效率的主要指标。在 checkpoint 期间,一般脏页 的刷新效率应大于 10000 页/秒;应小于 3 秒。脏页的刷新效率按如下方式计算:onstat –R 得到当前脏页数,立即进行 onmode –c,onstat -m 查看 checkpoint duration 时间,根据脏页 数量和 checkpoint duration 得到脏页的刷新效率。 监控命令: onstat -R ,onmode –c,onstat –m 输出示例: onstat –R 。。。。。。。 29501 dirty, 1999171 queued, 2000000 total, 2097152 hash buckets, 2048 buffer size start clean at 1.000% (of set total) dirty, or 317 buffs dirty, stop at 0.700% onmode –c onstat –m 。。。。。。 14:27:42 Maximum server connections 1059 14:31:08 Logical Log 116017 Complete, timestamp: 0x2b6fe7e. 14:33:27 14:33:27 Checkpoint loguniq 116018, logpos 0xd11636c, timestamp: 0x2c615af 。。。。。。 Checkpoint Completed: duration was 4 seconds, 28173 buffers not flushed. 相关参数: Checkpointerval:检查点间隔; LRU_MAX_DIRTY; LRU_MIN_DIRTY;控制检查点间隔内脏页的比例; PHYSFILE 物理日志文件大小,在前映像达到75%启动检查点; LRUS:影响写的效率; cleaner;影响写的效率… 2.3 IO 热点检查 概述: 检查在各 chunk 上的 IO 情况,关注 IO 读写量大的 chunk,发现是否存在 IO 热点,从 数据表的分布上考虑 IO 均衡问题。 5
监控命令: onstat -g iof, onstat –D 输出示例: IBM Informix Dynamic Server Version 9.40.FC8 7124992 Kbytes -- On-Line -- Up 100 days 13:52:29 -- AIO global files: gfd pathname 3 rootchk 4 plogchk 5 tmpchk1 6 tmpchk2 7 tmpchk3 8 tmpchk4 9 tmpchk5 10 tmpchk6 11 tmpchk7 12 tmpchk8 13 llogchk 14 idxchk 。。。。。。 229020 0.1 5.0 dskread dskwrite io/s 1057858 14 43124184 totalops 1286878 43124198 1417096872 519251612 897845260 163.1 1414894993 519078890 895816103 162.8 1415508436 518890537 896617899 162.9 1415892980 519442900 896450080 162.9 1418568172 519879164 898689008 163.2 1415575642 518637598 896938044 162.9 1414142347 518306737 895835610 162.7 1420263035 520884214 899378821 163.4 100754266 60533953 40220313 1794895610 1773922679 20972931 206.5 11.6 189 hpmchk2_g 2 0 2 0.0 相关参数: 无 2.4 chunk 写(ckpt)和 LRU 写的平衡 概述: 通过调整参数 LRU_MAX_DIRTY 和 LRU_MIN_DIRTY,可以对 chunk 写和 LRU 写的量 进行平衡,从而在 IDS 的 CPU 使用和 IO 效率间找到平衡,提高系统的可用性。chunk 写 和 LRU 写有如下特点: LRU 写 chunk 写 全局的 IO 操作 局部的 IO 操作 IO 效率较高 阻塞其他写操作 不阻塞其他写操作 IO 效率较低 当调低 LRU_MAX_DIRTY 和 LRU_MIN_DIRTY 时,LRU 写的量增大,CHUNK 写的量 减少;反之,相反。 监控命令: onstat –F 6
LRU Writes 6827990271 输出示例: IBM Informix Dynamic Server Version 9.40.FC8 Fg Writes 24 address 24d10c850 。。。 24d11c528 Chunk Writes 432531409 flusher 0 state L 85 181 31 L data -- On-Line -- Up 100 days 13:52:21 -- 7124992 Kbytes = 0X55 = 0Xb5 states: Exit Idle Chunk Lru9 相关参数: LRU_MAX_DIRTY; LRU_MIN_DIRTY;控制检查点间隔内脏页的比例; 2.5 是否使用 kaio 概述: 是否使用 kaio,对 IO 的效率影响很大,一般情况下,建议启用 kaio。kaio 的启用和 OS 有关,相关的信息可从 $INFORMIXDIR/release/en_us/0333//ids_machine_notes_xx.xx.txt 中 得到 监控命令: onstat –g ath 输出示例: IBM Informix Dynamic Server Version 9.40.FC8 Threads: tid 。。。。。。 rstcb tcb -- On-Line -- Up 100 days 13:52:21 -- 7124992 Kbytes prty status vp-class name 24db05808 24db10218 24db10218 24db10218 49 50 50 50 。。。。。。 15:18:18 Maximum server connections 1059 0 0 0 0 4 4 4 4 running sleeping forever ready running 1cpu 3cpu 3cpu 3cpu kaio kaio kaio kaio 相关参数: NUMCPUVPS 7 线程。 # Number of user (cpu) vps, 在每个 CPUVP 上有一个 kaio 2.6 表碎片检测 概述: IDS 的 table 或 index 空间以 extent 为单位进行分配,每个 extent 可看作一个碎片,表 7
碎片数量增长影响 IO 的性能,还可能造成该表无法申请新的空间。对于 2Kpage 的 IDS,允 许碎片数在 200 左右;4Kpage 的 IDS,允许碎片数在 400 左右。一般在表的 extent 数量大 于 100 时,进行数据整理,整理后的 extent 数量应小于 50。 建议在适当的时候进行数据整理,数据整理可能花费较长的时间。 数据整理的一般方法: 全库整理: 使用 dbexport/dbimport 工具,会自动调整大表的 extent 大小; 单表整理: unload 卸出数据,根据该表的数据量估算 extent size 和 next size 大小后重 建表,再倒入数据。 对于 index,可 drop 后重建。 以上操作完成后需要进行 UPDATE STATISTICS。 检测 通过 sql 脚本访问 sysmaster 数据库实现。 sysmaster - < sql_big10_ext.txt dbaccess SET ISOLATION TO DIRTY READ; SELECT a.dbsname,a.tabname, a.partnum, count(b.pe_size) ext_cnt, sum(b.pe_size) page_cnt FROM sysptprof a, sysptnext b WHERE a.partnum = b.pe_partnum AND dbsname[1,3]<>'sys' AND tabname[1,3]<>'sys' GROUP BY 1,2,3 INTO TEMP tmp_ext WITH NO LOG; CREATE INDEX idx_ext ON tmp_ext (dbsname,tabname,partnum); SELECT FIRST 10 dbsname[1,10], tabname[1,20], partnum, sum(ext_cnt) ext_cnt, SUM(page_cnt) page_cnt FROM tmp_ext GROUP BY 1,2,3 ORDER BY 4 DESC; EOF 输出示意: dbsname tabname partnum ext_cnt page_cnt 8
分享到:
收藏