他们是若何做到 最快的 Informix DBA?[网络技术]

在 4 月的 IIUG Informix Conference 上,我们举行了一次最快的 Informix DBA 比赛.我在一个简单的客户结账流程中增添了一些错误的 SQL,并在默许 ONCONFIG 文件中设置了一些错误的配置选项 —— 重建了平常生活中对比常见的挑衅.未改正的基准测试需求运行大约 30 分钟时间,我给参赛者的任务是让它能更快地运行.最快的一名 DBA 让它能在 4 分钟之内运行.在上一期文章中,我谈论了这项挑衅并列出了得胜者;这次,我将讲授他们是若何做到的.

  首先,解析问题

  成功的 DBA 都耗费了充足的时间来研究问题.我们在一个文档中描写基准测试,包含全部代码和预期后果.我们还在一个视频中描写了他们需求办理的问题,并展示了若何运行基准测试.

  花较长时间研究质料的选手获得了更好的成就,因为他们可以更好地专注于自己的任务.举例来说,我成心改变了情势,将缓冲畅通率设定为非常高的值,而最快的 DBA 在看了数据和情势后发现了这个问题.别的,基准测试系统只有一个磁盘,因此操纵 Informix 并行磁盘读取和写入并不没有太大的用处.全部成功的 DBA 首先都研究了问题、解析了事实,然后才开始制订筹划.

  Informix 配置:ONCONFIG 文件更改在肯定若何改正 Informix Dynamic Server (IDS) 配置文件历程中触及的一项挑衅是 ONCONFIG 文件.这些更改专门针对基准测试环境,并且不一定能实用于全部场景,但它们确切能为您供应一些关于 ONCONFIG 文件的启迪.

  BUFFERPOOL成就优异的 DBA 都增添了服务器所利用的缓冲数目.服务器拥有 3 GB RAM.最快的 DBA 利用了几近一半的 RAM 用作缓冲,成立一个 16 KB 分页大小的 dbspace（大于默许 2 KB 分页大小）,并分配了三分之一的内涵作为这个 16 KB 分页的缓冲.这办理了记录太大而无法适应默许 2 KB 分页大小的问题,它将记录保存在一同,并将大大都记录放在内存中.总的来说,我认为 BUFFERPOOL 调整对性能的影响最大.

最快的 DBA 还分外掌握了 BUFFERPOOL 的大小.而 BUFFERPOOL 过大会造成 OS 开始换出磁盘并会降低整个系统的速度.在增添缓冲时,您还需求考虑 Least Recently Used (LRU) 查询的数目,它们用于管理 BUFFERPOOL 中的全部这些额外的分页.最快的 DBA 增添了 LRU 查询,以便于越发有效地处理额外的内存.

  SHMVIRTSIZE,这是 Informix 将分配给工作空间和虚拟内存的内存量.全部较快的 DBA 增添了这个值.而最快的 DBA 增添的最多.SQL 中还有大量 “group by” 语句,因此增添虚拟内存并对 Parallel Database Query (PDQ) 流程履行一些更改可以让任务更多地在内存中完成.

  DS_TOTAL_MEMORY,这是 SHMVIRTSIZE 内存中将用于 PDQ 操作的内存量.其默许值非常小,增添这个值有助于排序和索引构建.

  DS_NONPDQ_QUERY_MEM,这是在未利用 PDQ 履行排序时分配给排序任务的内存量.由于基准测试系统上只有一个磁盘驱动器,因此 PDQ 并没有太大用处.增添这个参数有助于排序和索引构建.

  LOCKS,LOCKS 的数目和它们可用的内存量.假如此配置参数不够大,则 Informix 会动态增添它,但动态增添的值是非常有限的.最快的 DBA 都设置了 LOCKS 的数目,这样服务器就不需求动态增添这个值.

  RESIDENT,设置这个值可以将 Informix 保持在内存中,并告诉 OS 不要将数据库服务器换出到磁盘中.全部较快的 DBA 都设置了这个值,以便将 Informix 保持在内存中.CPU VP ——基准测试机构采取四核 CPU,并且可以支持四个 Informix CPU 虚拟处理器 (VP).全部较快的 DBA 都将 CPU VP 的数目设置为 3 到 4 之间,以便于操纵机械上的全部 CPU.

  DBSPACETEMP,我在基本配置中成立了一个暂时的 dbspace,但是并未在 ONCONFIG 文件中定义它,因此未利用它.而是将 rootdbs 用于排序和暂时文件.全部较快的 DBA 都改正了 ONCONFIG 文件,在此中标识并定义了这个参数.一些 DBA 乃至成立了两个或三个额外的暂时 dbspaces,因此 Informix 可以并行读取和写入 tempdbs.

一些最快的比赛者还改正了其他 ONCONFIG 参数,包含 PHYSBUFF、LOGBUFF、DIRECT_IO、VP_MEMORY_CACHE_KB 和 CLEANERS.很难肯定它们的作用有多大,但最快的 DBA 发现此中一些参数能极大提高速度.我还对比关注哪些参数未被更改.大概是时间不够,但没有人改正过 read-ahead 参数 RA_PAGES 和 RA_THRESHOLD,也没有人改正过 index-cleaning 参数和 BTSCANNER.

  Informix 情势更改

  我成心在数据库的两个表中利用了非常大的列:客户表中的 CHAR(2000) 列和账单表中的 CHAR(1000) 列.但是,这些空间普通都被浪费了.在客户表中,大约只利用了 100 个字符,而账单表中的字符都没有利用过.这不但浪费空间,还造成表溢出了 2 KB 分页,从而招致大大都缓冲 Thrashing 非常高的缓冲畅通率.有很多办理筹划可办理此问题,此中之一是改正表并将这些列转换为 LVARCHAR 列.此更改削减了在基准测试期间读取和写入的缓冲数目,并且大概对总体性能造成了最大的影响.

  一些 DBA 还对情势举行了另一项改正,行将账单表的索引成立工作移动到插入了全部数据之后举行,而不是在插入数据之前.这样可以更快地载入没有索引的表,并且成立的索引会愈抓紧凑和优化.此外,在 IDS 11.50 中,成立索引会对表自动履行 UPDATE STATISTICS HIGH,这将为 Informix 查询优化器供应关于表的更好的信息.一些 DBA 在客户表上增添了额外的索引,这有助于基准测试中的最后一项查询操作.

[1] [2]  下一页