ID #7786

Informix 11.5新特性介绍:第2部分

在Informix数据库使用过程中,当发生检查点操作时,会阻塞数据库应用程序的运行,直到检查点操作完成为止。这样,会显著降低数据库的性能。本文将给大家介绍 Informix 11数据库中的非阻塞检查点及 RTO 策略原理及应用实践,希望大家能够对非阻塞检查点及 RTO 策略有一个比较全面的了解。

我们知道,检查点是数据库服务器的一个非常重要的操作,用于将缓冲池内的事务和数据全部或部分清仓到磁盘,为数据库服务器生成一致性点,这样,当数据库服务器发生故障时,可以在已建立的点上重新启动。

检查点的目的在于定期将逻辑日志中的重新启动点向前移动。如果检查点不存在而且发生故障,那么数据库服务器应需要处理自系统重新启动以来逻辑日志中记录的所有事务。

完全检查点及模糊检查点

在版本Informix 11之前,Informix 有两种类型的检查点,一种是完全或同步检查点(Full or sync checkpoints),另一种是模糊检查点(Fuzzy checkpoints)。完全或同步检查点会将缓冲池内所有被修改的数据清仓到磁盘上,建立一个数据库服务器的一致点。通常,在发生完全或同步检查点操作时,数据库服务器中的事物被阻塞,直到检查点操作完成。当检查点持续时间很长,会对系统性能造成较大的影响。为了减少检查点对系统性能的影响,从 Informix 9.2 版本开始,Informix 引入了模糊检查点的概念,采用模糊检查点方式,同完全或同步检查点操作一样,将缓冲池内变化的数据清仓到磁盘上,但是,对数据库内置数据类型的 insert,update 及 delete 操作所改变的数据,不会被清仓到磁盘上,这样,每次模糊检查点操作持续的时间会大大减少,从而减少了对系统性能的影响。

当发生下述情况,系统会产生模糊检查点操作:

超过检查点间隔设定值,通常这个值在onconfig 配置文件的 CKPTINTVL 参数中设置。

物理日志达到总大小的 75%

执行诸如增加数据库空间、增加块(chunk)之类的管理事件

执行 onmode -c fuzzy 命令

而当发生下述情况,系统会产生完全或同步检查点操作:

当使用 ontape 或 ON-Bar 命令进行备份或恢复操作时

当数据库服务器完成快速恢复(fast recovery)或完全恢复(ull recovery)

每个逻辑日志空间一个检查点:Informix Dynamic Server 不能覆盖包含当前检查点的逻辑日志,所以它必须在转移到那个逻辑日志之前触发检查点

执行 onmode -c 命令

执行正常的数据库服务器关闭操作

当发生完全检查点操作或模糊检查点操作时,数据库服务器会执行以下一系列操作:

阻塞事务

将物理日志缓冲区中的数据清仓到磁盘

将缓冲区中被修改的数据清仓到磁盘。如果是模糊检查点操作,informix 页清除线程会将非 inserts, deletes, updates 操作产生的变化数据清仓到磁盘,而由 inserts, deletes, updates 操作产生的变化数据不会被清仓到磁盘上;如果是完全检查点操,informix 页清除线程会将所有变化的数据清仓到磁盘。

将检查点完成记录写到逻辑日志缓冲区中,同时,将检查点信息更新到系统的保留页中 (system reserve page) 。

将逻辑日志缓冲区中的数据清仓到磁盘上

逻辑上清空物理日志

在Informix 11 版本之前,不论是完全检查点操作还是模糊检查点操作都会阻塞事务,影响系统性能。因此,用户需要采用各种方法来尽量减少完全检查点操作及模糊检查点操作持续时间。通常,用户会将 LRU 参数调整的非常小,通过持续不断地清仓缓冲池中数据来减少检查点操作的时间。但是,当将 LRU 参数调整的非常小时,会降低写操作的缓冲,耗费大量的 CPU 资源,同时增加了对缓冲池的争用现象,同样也会影响系统 OLTP的性能。系统优化工作成为一项非常困难的工作。另外,当有大量事务被阻塞时,模糊检查点操作时间是不可预料的,同时,采用模糊检查点操作方式,数据库服务器的故障恢复的时间也变得不可预知。

在Informix 11 版本之前,检查点操作也会使用户在系统响应时间及系统可恢复性方面产生困惑:如果检查点的间隔短,系统恢复性能好,但会有更多的事务被阻塞;如果检查点的间隔长,更少的事务被阻塞,但系统恢复时间会更长。

非阻塞检查点

针对检查点上述的问题,从 Informix 11 版本开始,Informix 已将其检查点算法替换为事实上的非阻塞检查点算法。现在,Informix Dynamic Server 允许应用程序在发生检查点处理期间继续处理事务。 Informix Dynamic Server 监视工作负载及过去的检查点性能,并更加频繁地触发检查点以避免关键资源(如物理或逻辑日志)耗尽,确保事务在检查点处理期间不会受到阻塞。对于那些对响应时间很敏感的应用程序,原先使用主动 LRU 清仓减少检查点静止时间的方法可能被更改。由于事务处理在检查点处理期间不会受到阻塞,因此 LRU 清仓的主动性可能有所下降。让 LRU 清仓的主动性下降可以增强事务性能。

图 1. 显示了非阻塞检查点工作示意图
图 1. 显示了非阻塞检查点工作示意图

当系统触发非阻塞检查点操作时,首先短暂阻塞事务的处理,记录系统恢复信息,清仓逻辑日志缓冲区中的内容,记录检查点信息;之后,系统中的事务操作不再被阻塞,恢复继续运行,系统将内存中所有被修改的数据清仓到磁盘上,最后,将检查点的信息记载到系统保留页中,这样就完成了一个非阻塞检查点操作。我们可以看到,非阻塞检查点操作允许应用程序在发生检查点处理期间继续处理事务,事务不再被阻塞。

从 Informix 11 版本开始,Informix Dynamic Server V9 中引入的模糊检查点(fuzzy checkpoint)已经被摒弃。

检查点可在以下某个情境中出现:

当指定事件发生时。例如,每当将数据库空间添加到服务器或执行数据库备份时,检查点将出现。

通常,这些类型的事件会触发阻塞事务处理的检查点。因此,这些检查点称为阻塞检查点。

当资源限制发生时。例如,逻辑日志空间的每个范围需要检查点来保证日志具有开始快速恢复的检查点。数据库服务器将在物理日志达到总大小的 75% 时触发检查点,以避免物理日志溢出。

资源限制触发的检查点通常不会阻塞事务。因此,这些检查点称为非阻塞检查点。

但是,如果在检查点处理期间数据库服务器将要耗尽资源,那么在检查点处理的中段将出现事务阻塞,以保证耗尽资源之前检查点能够完成。如果事务被阻塞,那么服务器将更频繁的尝试触发检查点,以避免检查点处理期间的事务阻塞。

为了避免检查点阻塞事务处理,我们需要:

打开自动检查点特性。更频繁的检查点将发生。这可以防止由于缺少资源而发生阻塞。

增加物理日志或逻辑日志的大小。服务器将在在线日志中放置一条消息,建议增加哪种资源,以及它的大小应该是多少。

LRU 刷新调整的更积极,覆盖 AUTO_LRU_TUNING 参数。

自动检查点 AUTO_CKPTS

自动检查点引起数据库服务器触发更频繁的检查点,以避免事务阻塞。自动检查点尝试监视系统活动和资源使用情况(物理和逻辑日志使用情况以及缓冲池脏的程度)以能够及时地触发检查点,这样检查点的处理就可在物理日志或逻辑日志耗尽之前完成。

数据库服务器为逻辑日志空间的每个范围生成至少一个自动检查点。这保证了可开始快速恢复的检查点的存在。

我们可以使用 AUTO_CKPTS 配置参数可在数据库服务器启动时启用或禁用自动检查点。默认情况下,在配置文件中它是自动启用的。

在onconfig 文件中,我们可以设置下述参数:

AUTO_CKPTS 1

我们也可通过使用 onmode -wm 或 onmode -wf 来动态地启用或禁用自动检查点。

- turns off. 
 onmode – wm AUTO_CKPTS=0 
 onmode – wf AUTO_CKPTS=0 
 - turns on. 
 onmode – wm AUTO_CKPTS=1 
 onmode – wf AUTO_CKPTS=1

如果关闭了 AUTO_CKPTS,则 Informix Dynamic Server 只根据以下 4 个事件触发检查点:

诸如归档、onmode -c、增加数据库空间、启动和关闭服务器之类的管理事件

物理日志满了 75% 。确保物理日志较大,以避免在达到 CKPTINTVL之前发生检查点处理

每个逻辑日志空间一个检查点:Informix Dynamic Server 不能覆盖包含当前检查点的逻辑日志,所以它必须在转移到那个逻辑日志之前触发检查点

ONCONFIG 参数 CKPTINTVL

我们可以使用 onstat – g ckp 来监控系统检查点信息 , 以及建议资源分配信息。

onstat -g ckp 命令输出:

IBM Informix Dynamic Server Version 11.50.F -- On-Line -- Up 00:01:20 -- 299368 Kbytes 
 Auto Checkpoints=On RTO_SERVER_RESTART=60 seconds Estimated recovery time 7 seconds 
Critical Sections  Clock Total Flush Block # Ckpt Wait Long #Dirty 
 Interval Time Trigger LSN Time Time Time Waits Time Time Time Buffers 
 1 18:41:36 Startup 1:f8 0.0 0.0 0.0 0 0.0 0.0 0.0 4 
  2 18:41:49 Admin 1:11c12cc 0.3 0.2 0.0 1 0.0 0.0 0.0 2884 
 3 18:42:21 Llog 8:188 2.3 2.0 2.0 1 0.0 2.0 2.0 14438 
 4 18:42:44*User 10:19c018 0.0 0.0 0.0 1 0.0 0.0 0.0 39 
 5 18:46:21 RTO 13:188 54.8 54.2 0.0 30 0.6 0.4 0.6 68232 

Physical Log Logical Log Dskflu Total Avg Total Avg /Sec Pages /Sec Pages 
/Sec 4 3 0 1 0 2884 1966 163 4549 379 7388 318 10 65442 2181 39 536 21 
20412 816 1259 210757 1033 150118 735 

 Max Plog Max Llog Max Dskflush Avg Dskflush Avg Dirty Blocked 
 pages/sec pages/sec Time pages/sec pages/sec Time 
 8796 6581 54 43975 2314 0

onstat -g ckp 命令输出说明:

AUTO_CKPTS On/Off Displays if automatic checkpoints feature is on or off
RTO_SERVER_RESTART Seconds Displays the RTO policy. 0=RTO policy is off.
Estimated recovery time Seconds This is the estimated time it would take the IDS server to perform fast recovery.
Interval Number Checkpoint interval id
Clock Time Wall clock time This is the wall clock time that the checkpoint occurred
Trigger Text There are several events that can trigger a checkpoint. The most common are RTO, Plog or Llog (running out of logical log resources).
LSN Log position Log position of checkpoint
Total Time Seconds Total checkpoint duration from request time to checkpoint completion
Flush Time Seconds Time to flush bufferpools
Block Time Seconds Transaction blocking time
# Waits Number Number of transactions that blocked waiting for checkpoint
Ckpt Time Seconds amount of time it takes for all transactions to recognize a checkpoint has been requested
Wait Time Seconds Average time thread waited for checkpoint
Long Time Seconds Longest amount of time a transaction waited for checkpoint
# Dirty Buffers Number Number of buffers flushed to disk during checkpoint processing
Dskflu/Sec Number Number of buffers flushed to disk per sec during checkpoint processing
Plog Total Pages Number Total number of pages physically logged during the checkpoint interval
Plog Avg/Sec Number Average rate of physical log activity during the checkpoint interval
Llog Total Pages Number Total number of pages logically logged during the checkpoint interval
Llog Avg/Sec Number Average rate of logical log activity during the checkpoint interval

 

为了保存关于最近检查点性能的信息,Informix 11 在SYSMATER数据库中增加了下面两个表:

表 1. 用于检查点的新的 Sysmaster 表

描述
syscheckpoint 存放关于最近 20 个检查点的历史
sysckptinfo 跟踪检查点活动

LRU的自动调优 AUTO_LRU_TUNING

在Informix 11之前,数据库管理员常见的做法是将 LRU 刷新调得更积极,以便不断地排出 LRU,经常将 LRU_MIN_DIRTY 设置为 1,LRU_MAX_DIRTY 设置为 2,这样,检查点将更快地完成,因为要做的工作更少了,同时这也减少了其他线程等待检查点完成所需的时间。

但是,在Informix 11 中,由于在检查点期间事务处理不会被阻塞,因此不必将 LRU 刷新调得如此积极。通常,可以将 LRU_MIN_DIRTY 设置为 70,LRU_MAX_DIRTY 设置为 80 。将 LRU 刷新调得缓一些,可以提高写操作的缓冲,减少 CPU 资源的占用,并减少对缓冲池的争用现象,提高事务性能。在Informix 11 上,通过放缓 LRU 刷新可以明显提高性能。

但是,当系统出现下述情况,会自动将 LRU 刷新调整的更积极一些:

当系统中一个页错误替代了一个热页面,LRU 刷新积极度自动增加 1% 。

当系统发生了页置换前台写操作,则数据库服务器将 LRU 设置增加 10%,并且在随后的每个检查点继续增加 LRU 刷新,直到页置换前台写操作停止

自动 LRU 调整只是使 LRU 刷新变得更积极,而不能减少 LRU 刷新。自动 LRU 调整不是永久的,不会记录在ONCONFIG 文件中。 LRU 刷新会被重新设置为数据库服务器启动时使用的 ONCONFIG 文件中包含的值。

自动 LRU 调优对所有缓冲池都有影响,并且会调整 BUFFERPOOL 配置参数中的 LRU_MIN_DIRTY 和 LRU_MAX_DIRTY 值。

AUTO_LRU_TUNING 配置参数指定当服务器启动时是否启用自动 LRU 调优。默认情况下,在配置文件中 AUTO_LRU_TUNING 已被启用。

在onconfig 文件中,我们可以设置下述参数:

AUTO_LRU_TUNING 1

 

我们也可以使用 onmode -wm 或 onmode -wf 动态地启用或禁用 LRU 调优。

- turns off. 
 onmode – wm AUTO_LRU_TUNING= 0 
 onmode – wf AUTO_LRU_TUNING= 0 
 - turns on. 
 onmode – wm AUTO_LRU_TUNING= 1 
 onmode – wf AUTO_LRU_TUNING= 1

自动 AIO VP 调优 AUTO_AIOVPS

从 Informix 11 版本开始,我们可以使用 AUTO_AIOVPS 配置参数使数据库服务器可以在服务器检测到 AIO VP 没有跟上 I/O 工作负载时自动调整 AIO VP 和刷新线程的数量。

默认情况下,AUTO_AIOVPS 在配置文件中已启用。

在onconfig 文件中,我们可以设置下述参数:

AUTO_AIOVPS 1

 

我们也可以使用 onmode -wm 或 onmode -wf 动态地启用或禁用 AIO VP 和刷新线程的自动增加。

- turns off. 
 onmode – wm AUTO_AIOVPS=0 
 onmode – wf AUTO_AIOVPS=0 
 - turns on. 
 onmode – wm AUTO_AIOVPS=1 
 onmode – wf AUTO_AIOVPS=1

Recovery Time Objective (RTO) 策略

我们知道,当 Informix数据库执行崩溃恢复时,我们没有任何方法可以预测崩溃恢复将在什么时间完成,需要多少物理日志及逻辑日志。同时,也没有什么配置参数来优化崩溃恢复的性能:CKPTINTVL 不能根据工作负载的变化进行相应的调整,模糊检查点使崩溃恢复时间更加不可预测。

Informix Dynamic Server V11 引入了配置参数 RTO_SERVER_RESTART 。该参数指定数据库服务器将尝试完成恢复并回到联机或静态模式的秒数。如果出现了崩溃,需要使服务器回到联机模式,那么这个参数就很方便。通过配置参数 RTO_SERVER_RESTART,使得崩溃恢复时间可以被我们把握。

在逻辑重放的过程中,必须处理每个日志记录。在此处理中,必须从磁盘读取页面。这种 I/O 会大大降低日志重放的性能。如果不知道快速恢复的逻辑部分需要多少 I/O,就难于判断恢复需要多长时间。

为了实现这个目标,并在规定的秒数内变得可用, Informix Dynamic Server 必须管理快速恢复期间发生的 I/O 量。当配置 RTO_SERVER_RESTART 时,Informix Dynamic Server 利用物理日志以保存它认为在逻辑恢复中要用到的附加前像(before-image)。

在快速恢复的物理部分,缓冲池将自动装入从最近检查点前滚逻辑日志所需的数据页。这里不必从磁盘读页面,因为它已经在内存中,可以直接使用。

启用 RTO_SERVER_RESTART之后,数据库服务器 :

通过更频繁地触发检查点确保自动检查点没有用完关键资源(例如逻辑空间)而阻塞

忽略配置参数 CKPTINTVL

自动调整 AIO 虚拟处理器和清理线程的数量

自动调优 LRU 刷新,以接纳增加的检查点

Informix 通过 RAS_PLOG_SPEED 和 RAS_LLOG_SPEED 两个 ONCONFIG 参数来计算什么时侯触发检查点。 RAS_PLOG_SPEED 和 RAS_LLOG_SPEED 这两个 ONCONFIG 参数用于存放在快速恢复期间物理日志和逻辑日志恢复的速度。

RAS_PLOG_SPEED 最初是在物理日志初始化时设置的。

RAS_LLOG_SPEED 被初始化为 RAS_PLOG_SPEED的 1/8 。

每当发生快速恢复时,这两个值将被更新,以反映实际的恢复速度。它们的单位是页 / 秒。

IBM 将这两个参数包括在ONCONFIG 文件中,使得那些将 Informix Dynamic Server 嵌入到应用程序中的客户可以提供预先计算的值,从而不需要进行调优就能达到最佳性能。除非在IBM 技术支持的指导下,否则 DBA 不应修改这些值。

但是,启用 RTO_SERVER_RESTART 也有一些不好的地方:

存储用于逻辑恢复的页面会增加物理日志活动 -- 这可能影响事务的性能

增加检查点的频率 -- 可以通过增加物理日志的大小以缓和这一点

默认情况下,RTO_SERVER_RESTART 被禁用。该配置参数的取值范围如下表所示:

表 2. RTO_SERVER_RESTART 配置参数的值

RTO_SERVER_RESTART 设置 取值范围
Off 0
On 60-1800

可以通过手动地修改配置文件或者使用 onmode -wf RTO_SERVER_RESTART 以更改 RTO_SERVER_RESTART 配置参数。

RTO_SERVER_RESTART的新值在数据库服务器停止并重新启动之后生效。

onmode -wf RTO_SERVER_RESTART=60

当启用 RTO_SERVER_RESTART,系统中的物理日志、逻辑日志及缓冲池都要足够大来保存 RTO_SERVER_RESTART 时间周期内所有的修改。

如果物理日志或逻辑日志空间太小,检查点就会因为日志空间不够而被触发;如果缓冲池太小,快速恢复将执行清仓到磁盘的操作,产生 I/O,降低快速恢复效率,将不能满足 RTO的策略。

通常,对于缓冲池空间小于 4 千兆字节的系统,物理日志的大小可定在所有缓冲池总大小的 110% 。对于较大的缓冲池,以 4 千兆字节的物理日志空间开始,然后监视检查点活动。如果检查点出现太频繁,而且可能将影响性能,那么增加物理日志大小。

结论

Informix 11数据库中的非阻塞检查点技术是一个非常重要的技术,使用它,可以显著提高数据库性能,从 Informix 11 开始,非阻塞检查点是数据库默认的检查点操作。同样,当我们采用 Informix 11 中的 RTO 技术后,数据库的崩溃恢复操作时间也可以由我们自己把握,显著提高了数据库服务质量水平 SLA(Service Level Agreement)。有关非阻塞检查点及 RTO 策略更详细的信息,大家可以参考 Informix 信息中心的相关内容。


2011-07-01 19:25
阅读:
I'm VC , Just U know Y
本站部分文章来源于互联网,版权归原作者所有。

延伸阅读:

正确理解Informix的系统结构

在Informix中创建并使用函数索引

轻松掌握Informix多方面的参数设置对性能的影响

设计优质高效的Informix数据库运用程序

轻松掌握Informix数据库系统的维护技术