《监控 informix dynamic server 以获取更高性能》由会员分享，可在线阅读，更多相关《监控 informix dynamic server 以获取更高性能（14页珍藏版）》请在金锄头文库上搜索。
1、监控 Informix Dynamic Server 以获取更高性能简介不少书籍和文章都对 Informix Dynamic Server（IDS ）及其体系结构和性能调优进行了详尽论述，但专门讨论监控这一主题的却很少。但在 IDS 管理中有效的监控却至关重要。它能帮助我们收集系统和数据库性能方面有价值的统计信息，还能帮助我们很早就确定问题，以便我们能够在故障诊断和性能调优方面取得主动。在成功地安装和配置 Informix Dynamic Server 并实现了 Informix 数据库以后，对 Informix Dynamic Server 进行监控就成为了数据库管理员的头等大事。本文将详细
2、讨论如何在各个级别有效地监控 Informix Dynamic Server，同时会就确定 Informix 引擎和数据库问题提供一些常规技巧。文章将同时涵盖故障诊断和性能调优这两个方面。监控工具Informix 提供了两个主要的工具来监控系统和数据库性能：onstat 实用程序。 sysmaster 数据库中众多的系统监控接口（SMI）表，该数据库是在 IDS 首次初始化时自动创建的。 onstat 实用程序和 SMI 表都通过检查 IDS 共享内存活动来监控 IDS 性能，但它们给出那些统计信息的方式却有所不同。onstat 实用程序总是以固定的方式给出统计信息，而使用 SMI 表则允许您
3、以更有意义、更可读的格式重新组织那些统计信息。需要注意的一点是，无论是通过 onstat 收集还是在 SMI 表中收集，这些统计信息都是从系统重新引导或 IDS 初始化开始累积而来的。因此，对于那些统计信息我们必须格外小心，并且总是要考虑 IDS 运行时间。例如，服务器运行超过一个月所累积的 100000 条 bufwait 与一天所累积的 100000 条 bufwait 就完全不同。要获取当前的统计信息，我们必须执行 onstat -z 以清除旧值。Informix 还提供了一个图形监控工具 onperf。onperf 收集 IDS 服务器的性能统计信息，并将它们描绘成度量值。它还可以将那
4、些统计信息保存为文本文件以供日后分析。请参考 Performance Guide for Informix Dynamic Server以获取更多有关 onperf 实用程序的详细信息。IDS 活动可以分为三类：实例活动 数据库活动 会话活动 通过使用上面讨论的工具，我们可以有效地监控所有那些 IDS 活动。监控实例活动IDS 实例是指 Informix 共享内存、Informix 处理器、Informix 数据库以及分配给 Informix 的物理设备。以下是部分需要监控的最重要的实例活动。操作方式第一个也是最重要的实例活动当然是 IDS 的操作方式。 IDS 运行正常还是有问题，或是已当机
5、了？onstat -p 命令捕获了 IDS 的当前操作方式，如下所示：Informix Dynamic Server 2000 Version 9.21.UC4 - On-Line - Up 01:01:17 - 1654784 KbytesProfiledskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached86923 101304 3116565 97.21 1651 15022 26196 93.70 isamtot open start read write rewrite delete commit r
6、ollbk2585879 118500 286631 1032967 1972 914 2 2 0gp_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 seqscans3502 0 7065882 0 0 0 1266
7、11280 ixda-RA idx-RA da-RA RA-pgsused lchwaits10120 51 69387 79557 482 我们也可以查询 sysmaster 数据库中的 sysprofile 表来获取同样的统计信息。输出的第一行显示了当前的 IDS 操作方式。本例中，Informix 引擎是“On-Line” 。总共有六种操作方式，其中三种特别重要：Off-Line、Quiescent 和 On-Line。Off-Line 方式表明 IDS 当前没有在运行。 Quiescent 方式表明 IDS 正在以单用户方式运行，在这种方式下，只有 DBA 可以进行管理和维护工作。 O
8、n-Line 方式表明 IDS 正在正常运行，所有用户都可以连接到数据库服务器，并可以执行各种数据库操作。在大多数情况下，IDS 应该始终处于 On-Line 方式。如果因为种种原因 IDS 当机了或处于 Off-Line 方式，那么上面的命令将显示下面的消息：Shared memory not initialized for INFORMIXSERVER cassprod_shm在这种情况下，您需要检查消息日志或 Informix 联机日志，以进一步确定问题的根源（请参阅消息日志） 。除了当前的操作方式以外，上面的输出还提供了一些重要的 Informix 实例性能统计信息。两个 %cache
9、 字段表明 IDS 目前使用内存高速缓存的效率。第一个 %cache 字段显示了读高速缓存比例的百分比，而第二个则显示了写高速缓存比例。读高速缓存比例和写高速缓存比例会随应用程序及正在操作的数据的类型和大小而动态变化。但读高速缓存比例和写高速缓存比例一般都应该在 80 到 90 个百分点之间。这是十分保守的数字，应该根据具体环境加以调整。如果这些比例始终低于 80%，那么您需要考虑提高 Informix 配置文件中 BUFFERS 参数的值，以获取较高的读写高速缓存比例。较低的读写高速缓存比例表明 IDS 正在进行的磁盘读写操作比它应该进行的要多得多，这会大大降低数据库引擎的整体性能。输出的
10、seqscan 字段表明自数据库启动或联机以来执行了多少次顺序扫描。如果这个数字相当大，比如说超过了 100000，并且还在不断增加，那么这可能表明性能有问题，当系统处于 OLTP 环境时更是如此。因而，您需要做进一步的调查以搞清楚出现过多顺序扫描的根源。在本文的后面我们将更详细地讨论这一问题。ovlock 字段表明 IDS 在使用了最大数量的锁之后尝试过再使用锁的次数。如果该数字非零，那么您可能需要提高配置文件中 LOCKS 参数的值。 ovbuf 字段表明 IDS 在使用了最大数量的缓冲区之后尝试过再使用缓冲区的次数。如果该数字很大，比如说超过 100000，那么您需要提高 BUFFERS
11、 参数，以便用户在需要从磁盘访问数据时不必等待缓冲区。这会缩短响应时间，因而可以改善整体性能。我们还需要检查与 LRU 有关的参数，将它们的值调整到较低的 bufwait。请参考 Administrators Guide for Informix Dynamic Server以获取更多详细信息。另一组重要字段包括 ixda-RA、idx-RA、da-RA 及 RA-pgused。这些字段组合在一起表明 IDS 使用 Informix 预读机制的效率。预读是这样一种操作：它在顺序扫描或索引读期间提前将数据页的数目从磁盘读入内存。理想情况是，预读的页数（即 ixda-RA、idx-RA 和 da-
12、RA 之和）等于顺序扫描或索引读期间所使用的页数（即 RA-pgused） 。这表明预读的页百分之百地用于顺序扫描和索引读。如果二者之间存在显著的差异，比如正负差值达到 10000 以上，那么 IDS 目前就没有很有效地使用预读，而您可能需要调优您的预读参数（即 RA_PAGES 和 RA_THRESHOLD）以获取更好的性能。请参考 Administrators Guide for Informix Dynamic Server（本文称为 Administrators Guide）以获取有关如何调优这些参数的详细信息。消息日志消息日志也称为联机日志。它含有各种有关关键实例活动的信息，如检查点
13、的时间和持续时间、实例启动和停止、备份和恢复状态、逻辑日志备份状态以及对主要配置参数的更改。消息日志还包含关键的错误（Informix 称之为断言失败） ，如磁盘 I/O 错误、镜像错误、当机块、数据完整性错误以及共享内存错误等等。在发生断言失败时，消息日志通常会将我们引向有关断言失败的（“af.xxx” ）文件，该文件会记录在数据库引擎当机时有关实例活动的更详细信息，还会就如何解决这一问题给我们提供一些建议。以下内容摘自消息日志：00:57:53 00:57:53 Assert Failed: Unexpected virtual processor termination, pid =58
14、6, exit = 0x9 00:57:53 Who: Session(13709, omcadminnvlsys, 6538, 654709000)Thread(13740, sqlexec, 2704a558, 1)00:57:53 Results: Fatal Internal Error requires system shutdown00:57:53 Action: Restart OnLine00:57:53 See Also: /var/tmp/af.35acfee100:57:53 Stack for thread: 13740 sqlexec上面的输出告诉我们：某个 Info
15、rmix 虚拟处理器终止了，并毁坏了数据库引擎。当用户“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 KbytesDbspacesaddress number flags fchunk nchunks flags owner name6510c7d0 1 0x1 1 1 N informix rootdbs65866468 2 0x1 2 4 N informix airgen_idx_dbs658665b0 3 0x1 3 3 N informix spare658666f8 4 0x1 4 5 N i
