标题:
使用内存盘提高OLTP数据库的性能和可用性(2)使用内存盘提高数据库性能-2
[打印本页]
作者:
look_w
时间:
2018-5-23 15:50
标题:
使用内存盘提高OLTP数据库的性能和可用性(2)使用内存盘提高数据库性能-2
使用内存盘保存日志 在一些大型的应用系统上,数据库的数据可能会达到几百个 G 甚至更多。此时,使用内存盘保存整个数据库不太可行。但是,把读写频繁的日志文件建立在内存盘上,不但可以提高数据库的访问速度、增加磁盘寿命,还可以为高可用性配置提供便利。本部分描述,如何把日志文件单独存放在内存盘上。
用户在决定将日志文件存放在内存盘之前,首先需要计算日志文件的大小。运行时,当所有的活动日志文件被写满,尚未完成的事务就会失败,并被 rollback。因此,用户应保证日志的大小满足日常操作的要求。这需要考虑在通常情况下需要的日志大小,以及在两种极端情况需要的日志大小。这两种极端情况是:
在应用程序最繁忙的时候,这时并发的应用最多,但是每个应用占用的日志大小相对较小。此时,应通过实验,得出平均每个事务占用的日志数,并乘以并发的应用的个数。
在执行批量操作时,此时往往是业务不太繁忙的时候,但是执行批量操作的应用,往往会在一个事务中执行较多的操作。因此,往往需要占用相当大的日志文件。这种情况下,可以通过修改应用程序,强制应用在每执行几万到几十万个操作就执行一次 commit 或 rollback。这种控制一次提交数量的方法,还可以同时提高应用程序的效率。
在 DB2 数据库中,活动日志分为主要日志 (primary) 和次要日志 (second)。DB2 数据库的主要日志文件,会在数据库被“激活”的同时建立。这通常发生于第一次 connect 时 ( 有时用户可能会被第一次链接的漫长时间折磨的发狂,内存盘有治疗这种狂躁症的功效 J)。数据库运行时主要日志文件会被循环使用。通常设定主要日志文件的大小应满足绝大多数应用,在绝大多数时间的要求。
当未结束的事务将主要日志文件占满,数据库就会启用次要日志文件。次要日志文件也会被循环使用。所有的活动日志文件 ( 主要日志文件和次要日志文件 ) 一旦被分配就不会释放,直到数据库退出。因为,活动日志大小不够时,可能引起事务回滚,因此在实际业务系统上,次要文件往往被设置的足够大。但如果要使用内存盘作为活动日志目录,用户就要考虑在满足业务需求的前提下,尽量减小次要日志文件的大小。即使配置了溢出日志路径 (overflowlogpath),也是如此。
根据主要和次要日志的大小,用户可以选择内存盘的大小,并通过修改 NEWLOGPATH 参数,为日志文件指定存放目录。( 修改这个参数后,需要重新启动数据库才能生效。)
db2 update db cfg using NEWLOGPATH /db2data/log
当用户把日志文件放在内存盘后,日志缓冲区的作用会减小。因此,用户可以通过将日志缓冲区设置为较小的值,以节约内存。
db2 update db cfg using LOGBUFSZ 256
配置参数 在做过一些测试以后,用户可能会发现,单纯使用内存盘提高效率并不明显。这是因为许多数据库默认的参数,并不适合使用内存盘的情况,因此需要对许多参数进行配置,以提高性能,同时避免过度使用内存。
在了解如何进行配置前,用户首先需要了解 DB2 数据库的内存分配。下图描述了 DB2 如何进行内存分配。用户可以从 DB2 Information Center 中找到 DB2 进行内存分配的更详细的描述。
图 3。DB2 的内存分配
需要注意的是,在有的 Linux 系统上,内存盘占用的内存,不是在 mkfs 或 mount 时一次性分配的。在数据库运行期间,随着数据的写入,内存盘占用的内存会逐渐增大。此时,如果将 DB2 自动调整内存的功能打开,那么在业务高峰时,会导致内存盘和 DB2 数据库管理器争抢内存。因此,强烈建议用户关闭数据库的自调整内存功能,并对数据库的参数进行手动的调节。
db2 update db cfg using SELF_TUNING_MEM OFF
在进行参数调节时以下几个要点需要特别注意:
因为,内存盘的速度比磁盘的速度快很多,因此通过配置大 Bufferpool 来提高数据读写速度的方法,作用很小。但是,需要注意的是,数据库仍要把数据读入 Bufferpool,才能对其操作。因此,Bufferpool 至少要能容下所有未完成的事务和未完成的查询所要占用的数据页。用户应在业务高峰或进行最密集的批量操作时,通过实验确定 Bufferpool 的大小。
当数据库建立在磁盘上时,因为磁盘和内存速度的巨大差距,因此需要对 SQL 语句进行精致而复杂的优化。如果使用内存盘,这个优化过程就显的复杂而不必要。可以将 SQL 语句的优化等级降低为 3 或 2。( 对使用 XML 的用户,仍建议使用默认的优化级别 )db2 update db cfg using DFT_QUERYOPT 3
使用内存盘创建的数据库,因为所有的读写操作,实际上都仅在内存中进行,所以建立多个 Index 对写入速度的影响,明显减小。但是,Index 对读操作的效率提升仍然有效。基于这个特性,用户可以考虑适当多建一些 Index。
考虑合适的 runstats 时机。使用内存盘以后,对 runstats 有 2 个方面的影响。一方面,因为读写速度加快,对 runstats 的要求减低,这样可以减少 runstats 的运行频率。另一方面,因为运行 runstats 的速度更快,因此用户可以更频繁的运行 runstats。因此,用户应重新考虑 runstats 运行的时机。
使用内存盘创建的数据库,其数据的读写速度,与其在内存盘上所在的位置无关。因此,使用 reorg 提升速度的效果非常微弱。但是,数据库仍需要使用 reorg 来释放被删除的数据占用的空间。因此,用户需要根据内存盘的大小和数据的多少决定 reorg 的时机,而不是为了提高速度进行 reorg。
使用内存盘以后,数据库同时并发的事务可以得到很大提高。但是,任何一个并发的应用都需要占用一定的内存。过多的并发还会使 locklist 占用的内存增加,并增加锁等待的概率。因此,用户需要谨慎的根据服务器内存的数量和业务的需要,来确定允许的并发访问的数量,防止因为过多的并发带来的各种问题。
使用内存盘以后,主要的瓶颈不再是磁盘 IO。因此根据 CPU 数目,建立多 partition 的数据库,将有效提高读写速度。同时,修改并行相关的参数,提高并行度,也有助于提高读写速度。
如果建立多 partition 的数据库,那么建立多个内存盘,保证每个 partition 都访问一个盘。同时也为日志指定单独的内存盘。这样对提高效率是有帮助的。
对仅使用内存盘保存日志的用户,写操作时的主要瓶颈会由日志,转化到对表空间的读写上。适当增加 Bufferpool 可以减少对表空间的读写频率。
应谨慎修改 sort 和 join 相关的参数,保证尽可能的使用 HASH join。
欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)
Powered by Discuz! 7.0.0