工作负载特征和集群缓存工具 (CF)
CF 在 DB2 pureScale 实例中发挥着">重要作用，因为它管理所有 DB2 pureScale 成员之间的数据同步和锁，以维护数据一致性。要帮助在 DB2 pureScale 环境中实现最佳的性能，CF 必须能够有效地处理从成员传入的请求，以便在这些成员上继续执行语句。传入的 CF 请求量取决于对数据库运行的工作负载的各种特征。例如，具有高比例的读取操作的工作负载对锁定和读取页面的 CF 请求可能更少。发出更少的读取请求是因为，页面很有可能已经被读取并在成员的本地缓冲池 (LBP) 中仍然可用。需要更少的锁请求是因为，即使在完成事务后，成员仍会在页面上保留一个共享锁，这意味着未来需要共享锁请求的读取操作不需要再与 CF 进行通信。相反，写入操作密集的工作负载可能导致更多的 CF 读取请求。原因之一是，在某个成员将一个页面写入 CF 时，其他在 LBP 中具有相同页面的副本的成员在下次引用该页面时必须重新读取它，因为它们的本地副本不再是最新的。
最后一个示例将介绍数据共享的概念，这是 DB2 pureScale Feature 等共享数据数据库系统的一个基本特征。工作负载中的数据共享水平直接影响着成员和 CF 之间所需的通信量。成员之间的数据共享水平较低的分区工作负载不会生成太多的 CF 通信。在具有极少数据共享需求的工作负载中，出现针对前一个示例中涉及写入操作密集的工作负载的其他读取请求（可能由于一个成员修改一个页面所导致）的可能性更小。在成员之间具有高数据共享水平的写入密集型工作负载可能会在这些成员之间产生页面争用。当两个或更多成员争用一个页面时，就会执行一个页面回收流程。该流程会导致从某个成员获取该页面并将它提供给另一个成员，甚至在事务处理过程中也是如此。请求成员可以继续工作，无需等待持有它的成员提交其事务。尽管此流程通过使用无中断 RDMA 进行了显著优化，但合理地最小化通信始终是一个不错的做法。我们将在后面章节中进一步介绍页面回收。
CF 的 CPU 资源配置
对于大部分工作负载，每五个 DB2 pureScale 成员核心就需要一个 CF 核心。CF 是一个多线程应用程序，它使用轮询来最大程度地减少总体 CF 响应时间。针对 CF 而发出的请求由 CF 工作线程处理。强烈建议您为 CF 提供专门的核心，以避免 CF 工作线程与系统上其他使用 CPU 资源的进程争用 CPU 资源。作为一条经验规则，在 System x 机器上，CF 工作线程的数量应该等于核心数量减 1。
CF 的内存资源分配
合理的初始 CF 内存分配应该是所有 DB2 pureScale 成员的所有 LBP 的总大小的 35% - 40%。可以将此值分配给 cf_db_mem_sz 数据库配置参数。现在，您应该将大约 80% 的内存分配给全局缓冲池 (GBP)，将 15% 的内存分配给全局锁管理器 (GLM)，将 5% 的内存分配给共享通信区域 (SCA)。 回想一下，CF 的一个好处是 GBP 充当着已修改的数据库页面的缓存。当未在该成员的 LBP 中找到某个成员所需的页面时，该成员会从 CF 请求该页面。如果该页面位于 GBP 中，所有 CF 会将该页面发送到该成员，进而避免高成本的磁盘访问。一般而言，提高 GBP 的大小会导致更高的 GBP 命中率和改善的性能。要确定您的 GBP 命中率，可以使用 MON_GET_BUFFERPOOL 表函数。可以查看 DBA Cockpit 的缓冲池屏幕来获得相同的信息，该屏幕已经进行了增强，包含特定于 DB2 pureScale Feature 的监视信息（包括 GBP 命中率）。
避免页面回收
如果 DB2 pureScale 实例中的一个成员以某种冲突模式访问一个页面，而另一个成员被迫释放相同页面时，就会发生页面回收。尽管这对于改进一个集群的并发性而言是一个非常强大的算法，但它需要付出一定的代价。处理页面回收涉及到所涉及成员与 CF 之间传输争用的页面。首先，持有页面的成员将修改的页面发送到 CF 并释放它在该页面上持有的锁。在收到更新的页面后，CF 让该页面在其他成员的 LBP 中的所有副本都失效。此时，会对请求该页面的成员进行授权，允许他们访问该页面，在这之后，他们会从 CF 获取更新的页面。 尽管与 CF 的基于 RDMA 的通信非常快，但尽量减少页面争用（并因此减少页面回收）对于任何数据库系统而言仍是一个不错的做法，DB2 pureScale Feature 也不例外。