使用并发 I/O 改进 DB2 数据库性能

摘自：http://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1204concurrent/index.html

简介：

 并发 I/O 是 UNIX? 和 Linux? 平台中引入的一项功能，主要用在关系数据库系统中。本文将介绍 UNIX/Linux 文件系统中可使用的 I/O 机制之间的区别，以及如何在 IBM? DB2? 环境中利用并发 I/O 技术来改进数据库性能。

概述

并发 I/O 和缓存 I/O 是两个与文件系统相关联的功能。出于此原因，大部分 DB2 DBA 认为这两种技术的使用取决于存储和系统管理员的见识。然而，在 DB2 数据库环境中利用此技术是 DBA 的职责。事实上，IBM 的 DB2 专家推荐在数据库级别实现此技术，因为这使 DB2 Database Manager 能够控制，应该使用 O_CIO 标志打开哪些文件和不应该打开哪些文件。

本文将介绍并发和缓存 I/O 的概念，重点介绍二者之间的重要区别。更重要的是，它将介绍如何在 DB2 数据库环境中利用并发 I/O 技术改善 CPU 和内存利用率。

本文将介绍的主要主题如下：

• 缓存 I/O 以及它对 DB2 的影响：缓存 I/O 在应用程序向操作系统发出请求时如何工作，以及这对 DB2 等关系型 DBMS 有何影响。
• 并发 I/O (CIO) 以及它与 DB2 的关系：并发 I/O 的工作原理、直接 I/O 与并发 I/O 之间的区别、CIO 和原始设备之间的性能类似性，以及这些性能对 DB2 有何益处。
• 如何实现 CIO：与 DB2 相关的实现方面、该实现的简单性，以及使用它的适合时机。
• 使用 CIO（限制与局限）：无法或不应使用 CIO 的场景。
• 各种能从 CIO 获益的应用程序，以及真实世界中的使用示例。

什么是缓存 I/O？

当应用程序发出一个访问磁盘中的数据的请求时，操作系统可通过两种方式处理该请求：一种是直接从磁盘检索该数据，另一种是利用一个缓存区域，以便保留经常访问的数据以供快速访问。对每个请求执行物理 I/O 会影响性能，而在内存中拥有一个缓存经常访问的数据的缓冲区可改进数据检索过程。

文件缓冲区缓存的用途是通过将经常访问的数据放在主要内存中，最小化物理磁盘 I/O 的频率。结果是，在缓存命中比率很高时，文件缓冲区缓存的使用可非常有效地减少磁盘 I/O。这种数据检索方法常常称为缓存 I/O。当应用程序向操作系统发出一个读取请求时，操作系统首先在文件缓冲区缓存中查找需要的数据。如果在这里找到该数据，就会从缓存获取并写入应用程序缓冲区，无需进入磁盘。然而，如果请求的数据未在文件系统缓存中，操作系统必须从磁盘获取数据，并将它存储在文件系统缓存中，之后再将它传输到应用程序缓冲区。

图 1 显示了将 I/O 缓存用于数据读取操作的步骤。

1. 应用程序发出一个读取请求。
2. 操作系统在文件缓冲区中查找请求的数据。
3. 请求的数据未在文件缓冲区缓存中。
4. 操作系统从磁盘读取数据。
5. 读取的数据缓存在文件缓冲区缓存中。
6. 读取的数据从文件缓冲区缓存复制到应用程序缓存。

图 1. 如何将 I/O 缓存用于数据读取操作

缓存 I/O 的另一个优势是，操作系统可利用异步文件写入。换句话说，应用程序不需要等待一个写入操作完成，即可继续执行。与读取一样，缓存 I/O 尝试将要写入的数据缓存在文件系统缓冲区中，以改进未来的数据读取和最大程度地减少向磁盘写入的操作。因此，对于读取和写入请求，缓存 I/O 支持先读取，后写入，这在缓存命中率很高时有助于改善性能。

图 2 显示了将 I/O 缓存用于数据写入操作的以下步骤。

1. 应用程序发出一个写入请求。
2. 操作系统将数据从应用程序缓冲区复制到文件缓冲区缓存。
3. 应用程序继续执行，无需等待磁盘写入。
4. 同步守护进程发起对脏文件缓冲区缓存页面的定期刷新。
5. 将脏页面写入磁盘。

图 2. I/O 缓存如何用于数据写入操作

尽管数据缓存很适合大部分应用程序，但它是冗余的，对大部分 DB2 数据库部署常常没有必要。这是因为 DB2 拥有自己的缓存区域（表现为一个或多个缓冲池的形式），并且对于它的大部分操作，DB2 使用此缓存区域来存储被访问的数据。所以除了 DB2 缓冲池，文件系统缓存的使用实际增加了 CPU 和内存开销。系统内存的很大一部分常常被用于文件缓冲区缓存，将数据复制到文件系统缓存和从文件系统缓存复制到缓冲池会消耗更多的 CPU 资源。

对于具有缓存 I/O 的写入请求，操作系统会使用所谓的 Inode 锁定机制来执行写入序列化，以始终保持数据的完整性。结果是，当将缓存 I/O 用于 DB2 时，会引入另一种形式的开销，因为 DB2 依靠它自己的锁定机制来维护数据一致性和完整性。

什么是并发 I/O？

AIX 平台上的 JFS2 文件系统中引入的两项功能：直接 I/O (DIO) 和并发 I/O (CIO)。x86、x64 和 POWER 架构上的 Linux 发行版 SLES 9 及更高版本和 RHEL 4 及更高版本同时提供了对 DIO 和 CIO 的支持。直接 I/O 通过直接将数据从磁盘复制到合适的应用程序缓冲区，消除了与缓存 I/O 关联的双重缓冲。但是，直接 I/O 执行了写入序列化和 Inode 锁定来维护数据完整性。

另一方面，并发 I/O 提供了对数据的直接访问能力，无需这种额外的缓冲和锁定。这进而允许文件系统提供通常与原始设备关联的优势和性能益处。顺便说一下，通过消除缓冲和锁定获得性能提升，这是为什么这些设备难以管理，却常常用在文件系统上作为数据存储的首选原始设备的主要原因之一。随着并发 I/O 的引入，文件系统有可能会在原始设备中实现更快的性能和更加简便的管理。

正如前面所提及的，Inode 锁支持在文件级别执行写入序列化，以在使用缓存 I/O 和直接 I/O 的情况下维护数据的一致性。并发 I/O 绕过了这种 Inode 锁，允许多个线程同时对同一个文件执行读取和写入操作。

图 3 显示了使用并发 I/O 工作原理，步骤如下。

1. 应用程序发出数据请求。
2. 操作系统发起磁盘读取操作。
3. 将请求的数从磁盘据传输到应用程序缓存。

对于没有执行数据一致性和数据完整性的应用程序，并发 I/O 的使用可能导致数据损坏，因此应该避免。大部分关系数据库系统都使用了它们自己的应用程序缓存，并整合了复杂的锁定机制来管理数据访问和一致性。因此，对数据库应用程序使用并发 I/O 技术常常会改善性能，而不会带来数据损坏风险。而且在 DB2 数据库用例中，CIO 的实现允许 DB2 在进行内存与磁盘之间的数据移动时避开与读取/写入操作关联的 CPU 和内存额外开销。

如何为 DB2 实现 CIO 的最佳实践

通过使用指定的 -o cio 选项来装载文件系统，可以在磁盘级别上实现 CIO，也可通过使用 O-CIO 作为 Oflag 参数发出 open() 调用的方法在应用程序级别上实现 CIO。

借助 DB2，也可以通过 CREATE TABLESPACE 和 ALTER TABLESPACE SQL 语句的 NO FILESYSTEM CACHING 选项在数据库级别上实现 CIO 。当使用这些选项时，DB2 Database Manager 为识别的表空间发出适当的 O-CIO 调用。

在 DB2 9.1 中引入此选项之前，启用 CIO 的惟一方式是使用 CIO 选项装载文件系统。而且当以这种方式在基本文件系统级别上实现 CIO 时，该文件系统上的每个文件将得使用 CIO 打开。

但是，使用 CREATE TABLESPACE 和 ALTER TABLESPACE 语句的 NO FILESYSTEM CACHING 选项允许 DB2 Database Manager 确定哪些文件要使用 CIO 打开。这很重要，因为一些 DB2 文件可能会从文件系统缓存中获益，但在某些情形下，在全文件系统范围实现 CIO 可能不利。

要创建启用了 CIO 的表空间，您需要执行一个类似于清单 1 中所示的 CREATE TABLESPACE 语句。

清单 1. 创建启用了 CIO 的表空间

				
CREATE TABLESPACE mytspace 
MANAGED BY DATABASE PAGESIZE 4K
USING (FILE ‘….’)
    EXTENTSIZE 16K
    PREFETCH SIZE AUTOMATIC
    BUFFERPOOL MYBP NO FILESYSTEM CACHING; 

要更改现有表空间以使用 CIO，可执行类似于清单 2 中所示的 ALTER TABLESPACE 命令。

清单 2. 修改表空间以启用 CIO

				
ALTER TABLESPACE mytspace NO FILESYSTEM CACHING; 

如果使用 ALTER TABLESPACE 语句，更改将在数据库失效并重新激活之后才生效。

对于 DB2 v9.1，新表空间的默认设置为 FILE SYSTEM CACHING。对于 DB2 v9.5，默认在 AIX 上的 JFS、Linux System z，Solaris 上的所有非 VxFS 文件系统、HP-UX、所有平台上的 SMS 临时表空间文件，以及所有 LOB 与大数据中使用 FILESYSTEM CACHING。对于所有其他平台和表空间，默认使用 NO FILE SYSTEM CACHING。对于 DB2 9.7，新表空间默认使用 NO FILE SYSTEM CACHING 子句。已迁移到 V9.5 或 V9.7 的数据库仍然采用旧的默认设置。所以在 DB2 环境中，验证和实现 CIO 技术确实是 DBA 的职责。

使用 CIO（限制与局限）

在一些情形下，DB2 可从文件系统缓存的使用中获益，特别是在要频繁查询包含未以内联方式存储的 LOB 数据表的情形中。因为这些 LOB 数据从不会写入 DB2 缓冲池，所以如果允许文件系统缓存 LOB 数据读取和写入操作，性能会更好。相反，对于内联 LOB（与其他表数据存储在一起的 LOB），应用并发 I/O 将有助于减少双重缓存的开销；因为内联 LOB 的数据写入到了 DB2 缓冲池中，所以不需要文件系统缓存。

使用 SMS 存储的临时表空间（目录容器）也需要文件系统缓存。但对于所有其他表空间，推荐使用并发 I/O。

并发 I/O 的好处：一个真实示例

因为 CIO 消除了双重缓冲和不必要的文件锁定，所以具有 I/O 限制和 CPU 限制的应用程序都会从 CIO 的使用中获益。而且在 DB2 环境中实现 CIO 可释放 DB2 服务器上的内存和 CPU 资源（可用于其他应用程序的资源）。

例如，一位 DB2 客户在从较大型的服务器迁移到 CPU 数量有限的较小型 LPAR 时，遇到了严重的应用程序性能问题。应用程序在某种程度上变得非常缓慢，以至于无法处理任何事务。在大多数时间，CPU 利用率都高于 90%，这还影响了位于服务器上的其他应用程序。对正运行查询的 Explain 数据进行分析，结果显示，在迁移前后，源和目标之间没有任何重要区别，而且没有对应用程序代码或正在访问的数据卷执行任何其他更改。

起初，客户决定向 LPAR 添加更多 CPU，因为这似乎是源和目标之间惟一存在的区别。但是，在分析了问题的实际来源之后，发现数据库的所有数据表空间都未启用 CIO。换句话说，每个表空间都是在启用 FILESYSTEM CACHING 的情况下创建的。所以是使用以前提供的 ALTER TABLESPACE 命令向所有的数据表空间实现 CIO。

结果立竿见影。应用程序的性能得到了显著改善，事务处理速率比源服务器更快。服务器上的 CPU 利用率降到了 30%，在服务器上运行的其他应用程序能够恢复它们的正常功能。下表总结了之前之后的场景。

表 1. 在启用 CIO 之前和之后的客户 DB2 环境

系统配置	CPU 利用率（启用 CIO 之前）	CPU 利用率（启用 CIO 之后）
AIX 5.3 27 GB RAM 2 个 CPU DB2 V9.1 数据库大小：90G	CPU 利用率达到 90% 以上； 应用程序非常慢。	CPU 利用率下降到了 20-30%； 应用程序性能改善了 90%

验证 DB2 是否使用了 CIO 相对比较简单。db2look 实用程序的输出将显示特定的表空间是否使用指定的 NO FILESYSTEM CACHING 选项进行创建。数据库上的表空间快照也将提供此信息。另一种可用的方法是查看 SYSIBMADM 管理视图下的 SNAPTBSP 表，其中包含由表空间快照所获得的大部分信息。

结束语

并发 I/O 功能，尤其是它与 DB2 的关系在 DB2 社区中还鲜为人知。本文的目的是让更多的人知道此功能，帮助更多 DBA 尝试在其数据库环境中实现此技术。可以看到，在 DB2 环境中实现此功能非常轻松，可带来显著的性能优势。DB2 V9.7 默认使用 CIO，但是从以前版本迁移过来的都必须进行手动升级才能利用此功能。因此，执行数据库迁移之后，在表空间级别上实现 CIO 是 DBA 的职责。