|
简介
不少书籍和文章都对 Informix® Dynamic Server®（IDS）及其体系结构和性能调优进行了详尽论述，但专门讨论监控这一主题的却很少。但在 IDS 管理中有效的监控却至关重要。它能帮助我们收集系统和数据库性能方面有价值的统计信息，还能帮助我们很早就确定问题，以便我们能够在故障诊断和性能调优方面取得主动。在成功地安装和配置 Informix Dynamic Server 并实现了 Informix 数据库以后，对 Informix Dynamic Server 进行监控就成为了数据库管理员的头等大事。
本文将详细讨论如何在各个级别有效地监控 Informix Dynamic Server，同时会就确定 Informix 引擎和数据库问题提供一些常规技巧。文章将同时涵盖故障诊断和性能调优这两个方面。 监控工具
Informix 提供了两个主要的工具来监控系统和数据库性能：
onstat 实用程序。
sysmaster 数据库中众多的系统监控接口（SMI）表，该数据库是在 IDS 首次初始化时自动创建的。
onstat 实用程序和 SMI 表都通过检查 IDS 共享内存活动来监控 IDS 性能，但它们给出那些统计信息的方式却有所不同。onstat 实用程序总是以固定的方式给出统计信息，而使用 SMI 表则允许您以更有意义、更可读的格式重新组织那些统计信息。 需要注意的一点是，无论是通过 onstat 收集还是在 SMI 表中收集，这些统计信息都是从系统重新引导或 IDS 初始化开始累积而来的。因此，对于那些统计信息我们必须格外小心，并且总是要考虑 IDS 运行时间。例如，服务器运行超过一个月所累积的 100000 条 bufwait 与一天所累积的 100000 条 bufwait 就完全不同。要获取当前的统计信息，我们必须执行 onstat -z 以清除旧值。 Informix 还提供了一个图形监控工具 — onperf。onperf 收集 IDS 服务器的性能统计信息，并将它们描绘成度量值。它还可以将那些统计信息保存为文本文件以供日后分析。请参考 Performance Guide for Informix Dynamic Server 以获取更多有关 onperf 实用程序的详细信息。 IDS 活动可以分为三类： 实例活动
数据库活动
会话活动
通过使用上面讨论的工具，我们可以有效地监控所有那些 IDS 活动。 监控实例活动
IDS 实例是指 Informix 共享内存、Informix 处理器、Informix 数据库以及分配给 Informix 的物理设备。以下是部分需要监控的最重要的实例活动。
操作方式
第一个也是最重要的实例活动当然是 IDS 的操作方式。IDS 运行正常还是有问题，或是已当机了？onstat -p 命令捕获了 IDS 的当前操作方式，如下所示： Informix Dynamic Server 2000 Version 9.21.UC4 -- On-Line -- Up 01:01:17 --
1654784 Kbytes Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
86923 101304 3116565 97.21 1651 15022 26196 93.70 isamtot open start read write rewrite delete commit rollbk
2585879 118500 286631 1032967 1972 914 2 2 0 gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 478.11 71.63 13 26 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
3502 0 7065882 0 0 0 1266 11280 ixda-RA idx-RA da-RA RA-pgsused lchwaits
10120 51 69387 79557 482 我们也可以查询 sysmaster 数据库中的 sysprofile 表来获取同样的统计信息。 输出的第一行显示了当前的 IDS 操作方式。本例中，Informix 引擎是“On-Line”。总共有六种操作方式，其中三种特别重要：Off-Line、Quiescent 和 On-Line。Off-Line 方式表明 IDS 当前没有在运行。Quiescent 方式表明 IDS 正在以单用户方式运行，在这种方式下，只有 DBA 可以进行管理和维护工作。On-Line 方式表明 IDS 正在正常运行，所有用户都可以连接到数据库服务器，并可以执行各种数据库操作。在大多数情况下，IDS 应该始终处于 On-Line 方式。如果因为种种原因 IDS 当机了或处于 Off-Line 方式，那么上面的命令将显示下面的消息： Shared memory not initialized for INFORMIXSERVER 'cassprod_shm' 在这种情况下，您需要检查消息日志或 Informix 联机日志，以进一步确定问题的根源（请参阅消息日志）。 除了当前的操作方式以外，上面的输出还提供了一些重要的 Informix 实例性能统计信息。两个 %cache 字段表明 IDS 目前使用内存高速缓存的效率。第一个 %cache 字段显示了读高速缓存比例的百分比，而第二个则显示了写高速缓存比例。读高速缓存比例和写高速缓存比例会随应用程序及正在操作的数据的类型和大小而动态变化。但读高速缓存比例和写高速缓存比例一般都应该在 80 到 90 个百分点之间。这是十分保守的数字，应该根据具体环境加以调整。如果这些比例始终低于 80%，那么您需要考虑提高 Informix 配置文件中 BUFFERS 参数的值，以获取较高的读写高速缓存比例。较低的读写高速缓存比例表明 IDS 正在进行的磁盘读写操作比它应该进行的要多得多，这会大大降低数据库引擎的整体性能。 输出的 seqscan 字段表明自数据库启动或联机以来执行了多少次顺序扫描。如果这个数字相当大，比如说超过了 100000，并且还在不断增加，那么这可能表明性能有问题，当系统处于 OLTP 环境时更是如此。因而，您需要做进一步的调查以搞清楚出现过多顺序扫描的根源。在本文的后面我们将更详细地讨论这一问题。 ovlock 字段表明 IDS 在使用了最大数量的锁之后尝试过再使用锁的次数。如果该数字非零，那么您可能需要提高配置文件中 LOCKS 参数的值。ovbuf 字段表明 IDS 在使用了最大数量的缓冲区之后尝试过再使用缓冲区的次数。如果该数字很大，比如说超过 100000，那么您需要提高 BUFFERS 参数，以便用户在需要从磁盘访问数据时不必等待缓冲区。这会缩短响应时间，因而可以改善整体性能。我们还需要检查与 LRU 有关的参数，将它们的值调整到较低的 bufwait。请参考 Administrator's Guide for Informix Dynamic Server 以获取更多详细信息。 另一组重要字段包括 ixda-RA、idx-RA、da-RA 及 RA-pgused。这些字段组合在一起表明 IDS 使用 Informix 预读机制的效率。预读是这样一种操作：它在顺序扫描或索引读期间提前将数据页的数目从磁盘读入内存。理想情况是，预读的页数（即 ixda-RA、idx-RA 和 da-RA 之和）等于顺序扫描或索引读期间所使用的页数（即 RA-pgused）。这表明预读的页百分之百地用于顺序扫描和索引读。如果二者之间存在显著的差异，比如正负差值达到 10000 以上，那么 IDS 目前就没有很有效地使用预读，而您可能需要调优您的预读参数（即 RA_PAGES 和 RA_THRESHOLD）以获取更好的性能。请参考 Administrator's Guide for Informix Dynamic Server（本文称为 Administrator's Guide）以获取有关如何调优这些参数的详细信息。 消息日志
消息日志也称为联机日志。它含有各种有关关键实例活动的信息，如检查点的时间和持续时间、实例启动和停止、备份和恢复状态、逻辑日志备份状态以及对主要配置参数的更改。消息日志还包含关键的错误（Informix 称之为断言失败），如磁盘 I/O 错误、镜像错误、当机块、数据完整性错误以及共享内存错误等等。在发生断言失败时，消息日志通常会将我们引向有关断言失败的（“af.xxx”）文件，该文件会记录在数据库引擎当机时有关实例活动的更详细信息，还会就如何解决这一问题给我们提供一些建议。以下内容摘自消息日志： 00:57:53
00:57:53 Assert Failed: Unexpected virtual processor termination, pid =586, exit = 0x9
00:57:53 Who: Session(13709, omcadmin@nvlsys, 6538, 654709000)
Thread(13740, sqlexec, 2704a558, 1)
...... 上面的输出告诉我们：某个 Informix 虚拟处理器终止了，并毁坏了数据库引擎。当用户“omcadmin”登录到名为 nvlsys 的机器并执行了一些数据库操作（大部分是未正确执行的 SQL 查询），该机器上发生了这一错误。文件 /var/tmp/af.35acfeel 记录了出错时有关数据库引擎状态的详细统计信息。 块状态
块是物理存储设备。它们应该始终联机。如果有任何块当机了，那么这表明数据遭到毁坏，需要立即引起注意。onstat -d 命令监控当前的块状态，以下是该命令的输出： Informix Dynamic Server 2000 Version 9.21.UC4 -- On-Line -- Up 7 days 23:35:56 --
1654784 Kbytes Dbspaces
address number flags fchunk nchunks flags owner name
6510c7d0 1 0x1 1 1 N informix rootdbs
65866468 2 0x1 2 4 N informix airgen_idx_dbs
658665b0 3 0x1 3 3 N informix spare
658666f8 4 0x2001 4 5 N informix logs
.......
15 active, 2047 maximum Chunks
address chk/dbs offset size free bpages flags pathname
6510c918 1 1 0 63069 51985 PO- /usr/informix/dblink
6514b5f0 2 2 65000 750000 1 PO- /usr/informix/dblink
6514b760 3 3 815000 60000 59747 PO- /usr/informix/dblink
6514b8d0 4 4 875000 125000 4947 PO- /usr/informix/dblink ........
30 active, 2047 maximum 上面的输出包含两部分。第一部分列出了所有的 dbspace，第二部分则列出了所有的块。在块（Chunk）部分中，我们需要特别注意 flags 字段。该字段的第一个字符表明块是主（P）块还是镜像（M）块。第二个字符表明块的当前状态，是联机（O）还是脱机（D）。由于 O 和 D 看起来很相象，尤其是您匆匆一瞥时，因此您可能想将结果用管道输入到 grep PD，即 onstat -d |grep PD，以确保您不会遗漏任何当机块。如果有任何主块当机，那么您需要立即从备份磁带执行冷或暖恢复，以确保数据完整性。我们也可以查询 sysmaster 数据库中的 syschunks 和 sysdbspaces 表来获取类似的统计信息。 检查点
检查点是使磁盘上的页与共享内存缓冲池中的页同步的过程。在检查点期间，IDS 阻止用户线程进入临界会话，并阻止所有的事务活动。因此，如果检查点持续时间过长，那么用户可能会经历系统挂起。在存在几千个事务并且响应时间至关重要的 OLTP 环境中，情况尤其如此。正如上面所解释的那样，可以通过查看消息日志来监控检查点持续时间，但更好更快的方法是使用 onstat -m 命令。以下是该命令的样本输出： 15:25:10 Checkpoint Completed: duration was 0 seconds.
15:25:10 Checkpoint loguniq 231, logpos 0x1bb2018 Fri Dec 20 11:48:02 2002 11:48:02 Checkpoint Completed: duration was 7 seconds.
11:48:02 Checkpoint loguniq 231, logpos 0x32e5018 14:27:37 Logical Log 231 Complete.
14:27:40 Process exited with return code 142: /bin/sh /bin/sh -c
/usr/informix/etc/log_full.sh 2 23 "Logical Log 231 Complete." "Logical Log 231
Complete."
14:28:24 Checkpoint Completed: duration was 22 seconds.
14:28:24 Checkpoint loguniq 232, logpos 0x458018 如果检查点持续时间始终超过 10 秒，那么您可能需要减少 LRU_MIN_DIRTY 和 LRU_MAX_DIRTY 配置参数的值以获取更短的检查点持续时间。同样，如果 onstat -F 的输出显示极高的块写（比如高于 10000），并且这个数字还在不断增加，那么这可能表明出现了以下两个问题中的一个：要么检查点时间间隔太短，从而在检查点之间清除程序没有足够的时间将所有经过修改的缓冲区写入磁盘，要么 AIO VP 太少，无法在检查点期间共享繁重的磁盘写。这样，您需要重新检查 CKPINTVL、LRUS、CLEANERS 和 NUMAIOVPS 配置参数的设置，并相应地增加它们的值。我们可能还需要查看 onstat -F 的输出来作为确定那些参数值的参考。有关如何调优那些参数的详细信息，请参考 Administrator's Guide。 dbspace 使用情况
Informix 数据库管理员要不断了解各个 dbspace 中的空间，这一点十分重要。如果某个 dbspace 缺少空间或把空间用完了，那么 IDS 会碰到麻烦。各种问题都可能出现：无法导入任何数据库，无法创建任何表和索引，甚至无法对任何表和索引执行插入和更新操作。这一点对于生产数据库至关重要。我们需要监控每个 dbspace 的增长，以便能够对这些问题采取更主动的方法。下面的脚本报告了各个 dbspace 的当前空间使用情况，并计算其百分比。 select name dbspace, sum(chksize) allocated, sum(nfree) free,
round(((sum(chksize) - sum(nfree))/sum(chksize))*100) pcused
from sysdbspaces d, syschunks c
where d.dbsnum = c.dbsnum
group by name
order by name 输出如下所示： dbspace allocated free pcused airgen_idx_dbs 1000000 763405 24
llog 1000000 9947 99
rootdbs 50000 36220 28
temp1 250000 249947 0
上面的输出有助于我们确定哪些 dbspace 已把空间用完了。要取得主动，请考虑在某个 dbspace 的磁盘使用情况接近 90% 时向该 dbspace 分配额外的磁盘空间；本例中，我们需要特别注意 llog dbspace，并且可能的话，就给它分配更多空间，以防止它把空间用完。
dbspace I/O
Dbsapce I/O 是由磁盘读和磁盘写来衡量的。如果某些 dbspace 有繁重的磁盘读写操作，而另外一些 dbspace 几乎不进行任何读写操作，那么系统可能会出现一些磁盘 I/O 瓶颈。平衡得较好的 dbspace I/O 将减轻系统磁盘 I/O 负载，从而会改善系统的整体性能。以下脚本将显示各个 dbspace 的当前 I/O 统计信息： select d.name, fname[15,25] path_name, sum(pagesread) diskreads,
sum(pageswritten) diskwrites
from syschkio c, syschunks k, sysdbspaces d
where d.dbsnum = k.dbsnum
and k.chknum = c.chknum
group by 1, 2
order by 1 输出如下所示： name path_name diskreads diskwrites airgen_idx_dbs uild95/ltmp 3672 7964
airgen_main_dbs uild95/ltmp 13545 32903
llog uild95/ltmp 19 51633
rootdbs uild95/ltmp 211 43117
temp1 uild95/ltmp 3015 3122 我们的目标是要使所有的 dbspace 都有平衡的磁盘读写操作。在大多数情况下，这是不现实的，但上面的输出至少让您对 dbspace I/O 的分配方式有了一个概念，可以帮助您标识“最热门的”dbspace — 那些磁盘读写最多的 dbspace。如果有些 dbspace 的磁盘读写操作相当繁忙而另外一些的读写操作则相当空闲，那么您可能需要为 Informix 引擎调整甚至重新安排物理磁盘布局。我们可以使用 onstat -D 和 onstat -g ioq 获得类似的信息，前者显示各个块的磁盘读和写，而后者显示磁盘 I/O 等待队列信息。 您可以通过查询 sysmaster 数据库中的 sysptprof 表来进一步标识哪些表具有最多的磁盘读写操作： select dbsname, tabname, (isreads + pagreads) diskreads, (iswrites + pagwrites)
diskwrites
from sysptprof
order by 3 desc, 4 desc 输出类似于： dbsname tabname diskreads diskwrites airgen_10_0 fanout_param 84567 3094
airgen_cm_db sysindices 78381 0
airgen_10_0 ne_nmo_i 75819 5
airgen_10_0 ne_nmo 75440 297
airgen_cm_db sysprocbody 62610 28322
..... 根据从这个查询获得的输出，您可能需要在 dbspace 间移动一些表以使磁盘 I/O 平衡得更好。 共享内存段
太多的虚拟共享内存段（通常多于三个）表明：最初的虚拟共享内存段太小，数据库引擎必须不断分配额外的虚拟共享内存段。这反过来影响了 IDS 性能，并且最终会损害系统的性能。onstat -g seg 命令显示了 Informix 数据库引擎目前拥有多少共享内存段： Informix Dynamic Server 2000 Version 9.21.UC4 -- On-Line -- Up 28 days
15:49:33 -- 205824 Kbytes Segment Summary:
id key addr size ovhd class blkused blkfree
0 1381386241 a000000 177209344 220688 R 42984 280
1 1381386242 14900000 8388608 856 V 2048 0
2 1381386243 15100000 1048576 632 M 164 92
3 1381386244 15200000 8388608 856 V 2048 0
4 1381386245 15a00000 8388608 856 V 2008 40
5 1381386246 16200000 8388608 856 V 50 1998
Total: - - 211812352 - - 49302 2410 (* segment locked in memory) 如果输出显示虚拟共享内存段多于三个，那么您需要提高配置文件中 SHMVERSIZE 参数的值。其思想是，让 IDS 在初始化时分配足够的虚拟共享内存，以便在用户登录到系统并执行数据库操作时无需分配更多的虚拟共享内存。您可能还想使用 UNIX® ipcs 命令来查看 Informix 共享内存的大小。有关如何计算 IDS 虚拟共享内存段大小的详细信息，请参考 Administrator's Guide。 操作系统的整体性能
由于 Informix 数据库引擎总是安装在某个操作系统（主要是 UNIX）上，以准确地监控或评估 IDS 性能，因此我们需要将操作系统的行为作为一个整体来考虑，在数据库引擎驻留在非专用数据库服务器上时尤其要这样考虑。如果 IDS 占用了太多 RAM（例如，如果系统有 512MB RAM，而 IDS 占用了 400MB 或更多作为其共享内存），那么当用户执行内存密集型操作时，操作系统可能会经历频繁的交换和挂起。当内存不足时，系统必须将一些数据页从内存交换到磁盘，以便为新数据腾出更多空间。如果系统内存不足，那么 CPU 可能也会遭殃。有不少 UNIX 实用程序可以监控操作系统 CPU 和内存的整体利用率。以下是来自“top”实用程序的输出： load averages: 1.12, 1.02, 1.07 10:17:30
123 processes: 120 sleeping, 1 zombie, 2 on cpu
CPU states: 70.5% idle, 26.5% user, 2.8% kernel, 0.3% iowait, 0.0% swap
Memory: 3072M real, 76M free, 588M swap in use, 440M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
28349 omcadmin 4 0 0 86M 55M cpu10 970:25 6.85% CS_App.prt
17782 informix 5 30 -10 1631M 1594M sleep 50.0H 4.66% oninit.exe
571 root 1 58 0 361M 129M sleep 19.0H 1.36% em_mis
17785 informix 5 59 -10 1631M 1592M sleep 57.8H 1.05% oninit.exe
5470 omcadmin 1 0 0 1960K 1408K cpu15 0:00 0.26% top 上面的输出包含两部分。第一部分为您汇总了操作系统的 CPU 和内存的整体使用情况，第二部分则提供了有关每个处理器的详细信息。其它实用程序（如 vmstat、iostat、ps -ef 和 sar）在收集操作系统当前的性能统计信息方面也很有用。vmstat 显示目前操作系统交换了多少内存；iostat 和 sar 显示了当前在所有物理磁盘中磁盘 I/O 的分配；而 ps -ef 打印出当前各个处理器的登录时间、CPU 及内存使用情况的详细信息。此外也有许多图形工具可用，这些工具使您能够绘制操作系统资源利用率和性能的动态变化。 <下一页> |
