如何调优数据库注册变量DB2_USE_FAST_PREALLOCATION

尽管 DB2 pureScale 以高可用性、无限扩展性和对应用程序的透明性而著称，性能对于它来说同样重要。本文是 DB2 pureScale 在 Power 平台上的性能调优系列的又一个专题，主要关于如何调优数据库注册变量 DB2_USE_FAST_PREALLOCATION。

本文首先介绍了文件系统中和性能相关的很多方面，主要包括快速预分配和缓存，然后基于我们在实际试验中遇到的性能问题，归纳出在 DB2 pureScale 环境中调优注册变量 DB2_USE_FAST_PREALLOCATION 的最佳实践。

一方面，DB2 pureScale 基于共享数据 (share everything) 的架构设计，要求运行在 IBM 的 GPFS（General Parallel File System）文件系统之上。同 JFS2(Enhanced Journaled File System) 文件系统一样，GPFS 也支持快速预分配功能。快速预分配功能可以显著提高数据库中诸如数据库恢复、表空间创建、表空间大小修改等操作的性能。另一方面，DB2 pureScale 要求数据库中所有的表空间都是自动存储类型的表空间。对于自动存储表空间，容器的创建和空间的分配工作都由数据库管理器来按需进行。

默认情况下，DB2 会在支持 FAST_PREALLOCATION 特性的文件系统上开启该功能，来提高涉及修改表空间大小的操作的性能。我们在测试中发现，对于运行在 GPFS 上的 DB2 pureScale，开启快速预分配功能可以显著提高数据库恢复的性能，但对于运行时的性能却有很大影响。本文将详细阐述我们遇到的问题，分析产生问题的原因，最后给出关于该注册变量设置的最佳实践。

文件系统的快速预分配功能

在阐述我们遇到的问题之前，需要先了解一下文件系统的快速预分配功能。很多文件系统，如：JFS2、GPFS，都支持快速预分配功能。文件系统的快速预分配功能指的是：允许在不进行实际空间分配的情况下来改变一个文件的大小，实际空间的分配会在首次对对应新空间进行写的时候进行。也就是说，应用程序可以让文件系统承诺预留一定的空间给它，此时文件系统只需给应用程序一个承诺，而无需进行实际空间的分配。这样，文件大小的改变就会很快完成，而具体的空间分配工作会在后续进行实际写的时候进行。这种特性对于那些频繁涉及文件大小操作的应用有很大的好处。

对应到 DB2，默认情况下，DB2 会在支持快速预分配功能的文件系统上启用该功能，来提高涉及文件大小更改的数据库操作的性能，如数据库恢复、表空间创建、表空间大小修改。例如，当 DB2 需要创建一个新的表空间时，文件系统不需要立即进行实际空间的分配，实际空间会在 DB2 对对应空间首次插入数据的时候进行分配。而这种运行时实际空间分配带来的开销理论上也是可以忽略的。

文件系统的缓存功能

默认情况下，操作系统会对从磁盘读取或者要写入磁盘的数据进行缓存。这就是文件系统缓存的作用。典型的涉及物理磁盘操作的读过程是：先从磁盘上读取数据，把它放到文件系统的缓存中，然后再把数据从文件系统的缓存拷贝到应用程序的缓存中，这样应用程序才能使用这些数据。同样涉及物理磁盘操作的写过程是：首先把数据从应用程序缓存拷贝到文件系统缓存，然后再从文件系统缓存写到物理磁盘上。可见，文件系统的缓存位于应用程序缓存和磁盘之间，是应用程序和磁盘之间进行数据读写操作的桥梁。

图 1. IO 操作流程

对于那些本身没有缓存功能的应用程序，使用文件系统级别的缓存可以带来很大的性能提高。通过文件系统缓存的预读（read-ahead）和延迟写 (write-behind) 功能，应用程序可以节省很多花费在 IO 等待上时间，从而带来性能的极大提高。而对于像数据库这样的应用，它本身已经维护了自己的缓存池（bufferpool），如果在文件系统级别也启用缓存的话，将形成双重缓存的局面，会带来一些额外的 CPU 开销。所以为了避免文件系统和数据库系统重复缓存带来的额外开销，我们一般在数据库场景中会关闭文件系统的缓存功能。