Buffer Cache Buffer Cache 与 Shared Pool Shared Pool 原 理

Buffer Cache 与 Shared Pool 是 SGA 中的最重要和最复杂的两个部分，在此我们拿出一点
篇幅来对 Buffer Cache 和 Shared Pool 进行一点深入探讨。
6.1 Buffer Cache 原理
Buffer Cache 是 Oracle SGA 中一个重要部分，通常的数据访问和修改都需要通过 Buffer
Cache 来完成。当一个进程需要访问数据时，首先需要确定数据在内存中是否存在，如果数
据在 Buffer 中存在，则需要根据数据的状态来判断是否可以直接访问还是需要构造一致性
读取；如果数据在 Buffer 中不存在，则需要在 Buffer Cache 中寻找足够的空间以装载需要的
数据，如果 Buffer Cache 中找不到足够的内存空间，则需要触发 DBWR 去写出脏数据，释
放 Buffer 空间。
这样一个过程，᧿述起来并不复杂，但是在数据库的处理过程中实际上是相当复杂的。
在以上的᧿述中，有几个问题是我们需要考虑的，首先，Oracle 如何才能快速定位到 Buffer
中是否存在需要的数据呢？如果请求的数据在 Cache 中不存在，那么 Oracle 又是如何去
Buffer Cache 中快速寻找内存空间呢？
6.1.1 LRU 与 LRUW List
我们知道，在 Buffer Cache 中，Oracle 通过几个链表进行内存管理，其中最为熟知的是
LRU List 和 LRUW List（也经常被称为 Write/Dirty List），各种 List 上存放的是指向具体的
Buffer 的指针等信息。
从 Oracle8 开始，为了实施增量检查点，Oracle 还引入了检查点队列- Checkpoint Queue
和文件队列 – File Queue；从 Oracle8i 开始，由于异步 DBWn 的引入，现在关于各种 List
以及 Queue 的更为精确的概念是工作集（WS - Working Sets），在每个 WS 中包含几个不同
功能的 List，每个 List 都通过 Cache Buffers LRU CHAIN Latch 进行保护，当使用多个 DBWR
进程时（通过 DB_WRITER_PROCESSES 参数可以设置数据库使用多个 DBWR 进程），数
据库中会存在多个 WS，同时当使用 Buffer Cache 的多缓冲池技术时，每个独立的缓冲池也
会存在各自独立的 WS。
LRU List 用于维护内存中的 Buffer，按照 LRU 算法进行管理（在不同版本中，管理方
式有所不同），数据库初始化时，所有的 Buffer 都被 Hash 到 LRU List 上管理。当需要从数
据文件上读取数据时，首先要在 LRU List上寻找 Free 的 Buffer，然后读取数据到 Buffer Cache
书名书名书名书名书名书名书名书名书名书名书名书名书名书名
·2·
中；当数据被修改之后，状态变为 Dirty，就可以被移动至 LRUW List，LRUW List 上的都
是候选的可以被 DBWR 写出到数据文件的 Buffer，一个 Buffer 要么在 LRU List 上，要么在
LRUW List 上存在，不能同时在这两个 List 上存在。
图 6-1 是 Buffer Cache 中 LRU 及 LRUW List 的简要示意图。
图 6-1 LRU 与 Write List
检查点队列（Checkpoint Queue）则负责按照数据块的修改顺序记录数据块，同时将 RBA
和数据块关联起来，这样在进行增量检查点时，数据库可以按照数据块修改的先后顺序将其写
出，从而在进行恢复时，可以根据最后写出数据块及其相关的 RBA 开始进行快速恢复。在检
查点触发时 DBWR 根据检查点队列执行写出，在其他条件触发时，DBWR 由 Dirty List 执行
写出。检查点队列的内存在 Shared Pool 内存中分配：
SQL> select * from v$version where rownum <2;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
SQL> select * from v$sgastat where name='Checkpoint queue';
POOL NAME BYTES
------------ -------------------------- ----------
shared pool Checkpoint queue 128320
同样具有相关 Latch 对其进行保护：
SQL> col name for a40
SQL> select name ,gets,misses from v$latch where name like '%checkpoint queue%';
NAME GETS MISSES
---------------------------------------- ---------- ----------
active checkpoint queue latch 98706 0
第 1 章 章名章名章名章名章名
·3·
checkpoint queue latch 1508091 0
可以通过图 6-2 来详细介绍一下 Buffer Cache 的原理及使用。
图 6-2 Buffer Cache 的原理及使用
1． 当一个 Server 进程需要读数据到 Buffer Cache 中时，首先必须判断该数据在 Buffer
中是否存在（图中①所示过程），如果存在且可用，则获取该数据，同时根据 LRU
算法增进其访问计数；如果 Buffer 中不存在该数据，则需要从数据文件上进行读
取。
2． 在读取数据之前，Server 进程需要扫᧿ LRU List 寻找 Free 的 Buffer，扫᧿过程中
Server 进程会把发现的所有已经被修改过的 Buffer 注册到 LRUW List 上（图中②
所示过程），这些 Dirty Buffer 随后可以被写出到数据文件
3． 如果 LRUW Queue 超过了阀值，Server 进程就会通知 DBWn 去写出脏数据（图
中③所示过程）；
这也是触发 DBWn 写的一个条件，这个阀值曾经ᨀ到是 25%，也就是当 Dirty
Queue 超过 25%满就会触发 DBWn 的写操作：
SQL> select kvittag,kvitval,kvitdsc from x$kvit
2 where kvittag='kcbldq';
KVITTAG KVITVAL KVITDSC
-------------------- ---------- ----------------------------------------------------
kcbldq 25 large dirty queue if kcbclw reaches this
如果 Server 进程扫᧿ LRU 超过一个阀值仍然不能找到足够的 Free Buffer，将停
书名书名书名书名书名书名书名书名书名书名书名书名书名书名
·4·
止寻找，转而通知 DBWn 去写出脏数据，释放内存空间。
同样这个阀值可以从以上字典表中查询得到，这个数字是 40%，也就是说当
Server 进程扫᧿ LRU 超过 40%还没能找到足够的 Free Buffer 就会停止搜索，通知
DBWn 执行写出，这是进程会处于 free buffer wait 等待：
SQL> select kvittag,kvitval,kvitdsc from x$kvit
2 where kvittag='kcbfsp';
KVITTAG KVITVAL KVITDSC
-------------------- ---------- --------------------------------------------------------
kcbfsp 40 Max percentage of LRU list foreground can scan for free
同时我们知道，由于增量检查点的引入，DBWn 也会主动扫᧿ LRU List，将发现的
Dirty Buffer 注册到 Dirty List 以及 Checkpoint Queue，这个扫᧿也受一个内部约束，在
Oracle9iR2 中，这个比例是 25%：
SQL> select kvittag,kvitval,kvitdsc from x$kvit
2 where kvittag='kcbdsp';
KVITTAG KVITVAL KVITDSC
-------------------- ---------- --------------------------------------------------------
kcbdsp 25 Max percentage of LRU list dbwriter can scan for dirty
4． 找到足够的 Buffer 之后，Server 进程就可以将 Buffer 从数据文件读入 Buffer Cache
（图中④所示过程）
5． 如果读取的 Block 不满足读一致性需求，则 Server 进程需要通过当前 Block 版本
和回滚段构造前镜像返回给用户。
从 Oracle 8i 开始，LRU List 和 LRUW List 又分别增加了辅助 List（AUXILIARY List），
用于ᨀ高管理效率。引入了辅助 List 之后，当数据库初始化时，Buffer 首先存放在 LRU 的辅
助 List 上（AUXILIARY RPL_LST），当被使用后移动到 LRU 主 List 上（MAIN RPL_LST），
这样当用户进程搜索 Free Buffer 时就可以从 LRU-AUX List 开始，而 DBWR 搜索 Dirty Buffer
时，则可以从 LRU-Main List 开始，从而ᨀ高了搜索效率和数据库性能。
可以通过如下命令转储 Buffer Cache 的内容，从而清晰的看到以上᧿述的数据结构：
alter session set events 'immediate trace name buffers level 4';
不同 level 转储的内容详细程度不同，此命令的可用级别主要有 1～10 级，其中各级别的
含义如下。
¡ Level 1：仅包含 Buffer Headers 信息。
¡ Level 2：包含 Buffer Headers 和 Buffer 概要信息转储。
¡ Level 3：包含 Buffer Headers 和完整 Buffer 内容转储。
¡ Level 4：Level 1 + Latch 转储 + LRU 队列。
¡ Level 5：Level 4 + Buffer 概要信息转储。
¡ Level 6 和 Level 7：Level 4 + 完整的 Buffer 内容转储。
¡ Level 8：Level 4 + 显示 users/waiters 信息。
¡ Level 9：Level 5 + 显示 users/waiters 信息。
¡ Level 10：Level 6 + 显示 users/waiters 信息。
第 1 章 章名章名章名章名章名
·5·
转储仅限于在测试环境中使用，转储的跟踪文件可能非常巨大，为获取完整的跟踪文件，
建议设置初始化参数 max_dump_file_size 为 UNLIMITED。
本章节选取的环境为：
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
主要相关参数设置为：
SQL> show parameter max_dump
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
max_dump_file_size string UNLIMITED
SQL> show parameter memory_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
memory_target big integer 500M
从 Level 4 级跟踪文件的开头部分可以获得如下信息，这是记录的不同 List 的 Prev 和 Next
定位信息。其中 WS 就是指 Working Sets，注意 WSID 指不同 WS 的编号：
Dump of buffer cache at level 4 for tsn=2147483647, rdba=0
(WS) size: 0 wsid: 1 state: 0
(WS_REPL_LIST) main_prev: 0x3e102164 main_next: 0x3e102164 aux_prev: 0x3e10216c aux_next:
0x3e10216ccurnum: 0 auxnum: 0
cold: 3e102164 hbmax: 0 hbufs: 0
(WS_WRITE_LIST) main_prev: 0x3e102180 main_next: 0x3e102180 aux_prev: 0x3e102188 aux_next:
0x3e102188curnum: 0 auxnum: 0
(WS_XOBJ_LIST) main_prev: 0x3e10219c main_next: 0x3e10219c aux_prev: 0x3e1021a4 aux_next:
0x3e1021a4curnum: 0 auxnum: 0
(WS_XRNG_LIST) main_prev: 0x3e1021b8 main_next: 0x3e1021b8 aux_prev: 0x3e1021c0 aux_next:
0x3e1021c0curnum: 0 auxnum: 0
(WS_REQ_LIST) main_prev: 0x3e1021d4 main_next: 0x3e1021d4 aux_prev: 0x3e1021dc aux_next:
0x3e1021dccurnum: 0 auxnum: 0
(WS) fbwanted: 0
(WS) bgotten: 0 sumwrt: 0
(WS) pwbcnt: 0
接下来是具体的 List 链表信息，注意这里存在多条 NULL 列表，这是为 Buffer Cache 不
书名书名书名书名书名书名书名书名书名书名书名书名书名书名
·6·
同部分（Keep 池、Recycle 池以及不同 block_size 大小的内存使用）预分配的 List：
MAIN RPL_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN RPL_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY RPL_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY RPL_LST Queue header (PREV_DIRECTION)[NULL]
MAIN WRT_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN WRT_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY WRT_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY WRT_LST Queue header (PREV_DIRECTION)[NULL]
MAIN XOBJ_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN XOBJ_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY XOBJ_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY XOBJ_LST Queue header (PREV_DIRECTION)[NULL]
MAIN XRNG_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN XRNG_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY XRNG_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY XRNG_LST Queue header (PREV_DIRECTION)[NULL]
MAIN REQ_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN REQ_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY REQ_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY REQ_LST Queue header (PREV_DIRECTION)[NULL]
(WS) size: 12948 wsid: 3 state: 0
(WS_REPL_LIST) main_prev: 0x2d7e982c main_next: 0x2efeef1c aux_prev: 0x317ef0bc aux_next:
0x2efee48ccurnum: 12948 auxnum:
3195
cold: 2d7e9f7c hbmax: 6450 hbufs: 6096
(WS_WRITE_LIST) main_prev: 0x3e102888 main_next: 0x3e102888 aux_prev: 0x3e102890 aux_next:
0x3e102890curnum: 0 auxnum: 0
(WS_XOBJ_LIST) main_prev: 0x3e1028a4 main_next: 0x3e1028a4 aux_prev: 0x3e1028ac aux_next:
0x3e1028accurnum: 0 auxnum: 0
(WS_XRNG_LIST) main_prev: 0x3e1028c0 main_next: 0x3e1028c0 aux_prev: 0x3e1028c8 aux_next:
0x3e1028c8curnum: 0 auxnum: 0
(WS_REQ_LIST) main_prev: 0x3e1028dc main_next: 0x3e1028dc aux_prev: 0x3e1028e4 aux_next:
0x3e1028e4curnum: 0 auxnum: 0
(WS) fbwanted: 0
(WS) bgotten: 31531 sumwrt: 38791
(WS) pwbcnt: 0
从以上输出还可以看到，Buffer Cache 中除了 RPL_LST 和 WRT_LST 外还存在其他分类
的 List，作用各不相同。Buffer Cache 的多缓冲池以及多 WS 结构如图 6-3 所示.
第 1 章 章名章名章名章名章名
·7·
图 6-3 Buffer Cache 的多缓冲池
同时在 Level 4 级的专储中，再向下可以看到主要 RPL_LST 的队列信息，这也是链表的
一个最直观表现：
MAIN RPL_LST Queue header (NEXT_DIRECTION)[0x2efeef1c,0x2d7e982c]
0x2efeeebc=>0x2f3ebdfc=>0x2f3ebecc=>0x2eff03dc=>0x2f3ebabc=>0x2eff04ac=>0x2f3ee0ec=>0x2eff064c
0x2f3ec6ec=>0x2eff07ec=>0x2f3f3ffc=>0x2eff0ccc=>0x2eff0a5c=>0x2f3ee69c=>0x2f3ee76c=>0x2eff175c
0x2eff100c=>0x2eff10dc=>0x2f3f0bfc=>0x2f3f592c=>0x2f3f4a8c=>0x2f3f48ec=>0x2eff182c=>0x2eff1b6c
0x2eff1a9c=>0x2f3f56bc=>0x2f3f7c1c=>0x2eff1d0c=>0x2f3fa31c=>0x31be670c=>0x317f38ac=>0x2eff2adc
0x2f3f802c=>0x2f3f9fdc=>0x31ff14ec=>0x2cff89ec=>0x31ff15bc=>0x31ff168c=>0x31ff182c=>0x31ff1eac
0x31ff1f7c=>0x2dfea59c=>0x2dfea80c=>0x2dfea9ac=>0x2dfeacec=>0x2dfeb0fc=>0x2dfeb29c=>0x2dfeb43c
6.1.2 Cache Buffers LRU Chain 闩锁竞争与解决
当用户进程需要读数据到 Buffer Cache 时或 Cache Buffer 根据 LRU 算法进行管理等，就
不可避免的要扫᧿ LRU List 获取可用 Buffer 或更改 Buffer 状态，我们知道，Oracle 的 Buffer
Cache 是共享内存，可以为众多并发进程并发访问，所以在搜索的过程中必须获取 Latch（Latch
是 Oracle 的一种串行锁机制，用于保护共享内存结构），锁定内存结构，防止并发访问损坏内
存中的数据（我们必须认识到对于数据的访问、Buffer 的存取就意味着多次的 Latch 访问，而
过于严重的 Latch 竞争常常是系统的瓶颈所在）。
这个用于锁定 LRU 的 Latch 就是我们经常见到的 Cache Buffers Lru Chain。
SQL> col name for a25
SQL> select addr,latch#,name,gets,misses,immediate_gets,immediate_misses
2 from v$latch where name = 'cache buffers lru chain';
ADDR LATCH# NAME GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES
-------- --- ------------------------- ---------- ---------- -------------- ----------------
1200BFA8 93 cache buffers lru chain 40851181 11972 4608605853 2965271
Cache Buffers Lru Chain Latch 存在多个子 Latch，其数量受隐含参数_db_block_lru_latches
控制：
SQL> @GetParDescrb.sql
Enter value for par: lru
书名书名书名书名书名书名书名书名书名书名书名书名书名书名
·8·
old 6: AND x.ksppinm LIKE '%&par%'
new 6: AND x.ksppinm LIKE '%lru%'
NAME VALUE DESCRIB
------------------------------ -------------------- --------------------------------
_db_block_lru_latches 64 number of lru latches
可以从 v$latch_children 视图察看当前各子 Latch 使用情况：
SQL> select addr,child#,name,gets,misses,immediate_gets igets,immediate_misses imisses
2 from v$latch_children where name = 'cache buffers lru chain';
ADDR CHILD# NAME GETS MISSES IGETS IMISSES
-------- ------ ------------------------- --------- ---------- ---------- ----------
14C7E7F4 64 cache buffers lru chain 174 0 0 0
14C7E328 63 cache buffers lru chain 174 0 0 0
……
14C73678 27 cache buffers lru chain 174 0 0 0
14C731AC 26 cache buffers lru chain 174 0 0 0
14C72CE0 25 cache buffers lru chain 174 0 0 0
14C72814 24 cache buffers lru chain 5168833 2009 570411112 391045
14C72348 23 cache buffers lru chain 5179461 1685 577348879 369675
14C71E7C 22 cache buffers lru chain 5079655 1526 570766961 368414
14C719B0 21 cache buffers lru chain 5082539 1466 579774239 373785
14C714E4 20 cache buffers lru chain 5077378 1288 572272107 360877
14C71018 19 cache buffers lru chain 5084936 1396 586932913 368418
14C70B4C 18 cache buffers lru chain 5120549 1309 572987405 363633
14C70680 17 cache buffers lru chain 5069659 1296 578336549 369442
14C701B4 16 cache buffers lru chain 174 0 0 0
……
14C6C358 3 cache buffers lru chain 174 0 0 0
14C6BE8C 2 cache buffers lru chain 174 0 0 0
14C6B9C0 1 cache buffers lru chain 174 0 0 0

64 rows selected.
如果该 Latch 竞争激烈，通常有如下方法可以采用：
（1） 适当增大 Buffer Cache，这样可以减少读数据到 Buffer Cache 的机会，减少扫᧿
Lru List 的竞争。
（2） 可以适当增加 LRU Latch 的数量，修改_db_block_lru_latches 参数可以实现，但
是该参数通常来说是足够的，除非在 Oracle Support 的建议下或确知该参数将带来的
影响，否则不推荐修改。
（3） 通过多缓冲池技术，可以减少不希望的数据老化和全表扫᧿等操作对于 Default
池的冲击，从而可以减少竞争。
第 1 章 章名章名章名章名章名
·9·
（4） 优化 SQL，减少数据读取，从而减少对于 LRU List 的扫᧿。
6.1.3 Cache Buffer Chain 闩锁竞争与解决
在 LRU 和 Dirty List 这两个内存结构之外，Buffer Cache 的管理还存在另外两个重要的数
据结构：Hash Bucket 和 Cache Buffer Chain。
1．Hash Bucket 和 Cache Buffer Chain
我们可以想象，如果所有的 Buffer Cache 中的所有 Buffer 都通过同一个结构管理，当需要
确定某个 Block 在 Buffer 中是否存在时，将需要遍历整个结构，性能会相当低下。
为了ᨀ高效率，Oracle 引入了 Bucket 的数据结构，Oracle 把管理的所有的 Buffer 通过一
个内部的 Hash 算法运算后存放到不同 Hash Bucket 中，这样通过 Hash Bucket 进行分割之后，
众多的 Buffer被分布到一定数量的 Bucket之中，当用户需要在 Buffer中定位数据是否存在时，
只需要通过同样的算法获得 Hash 值，然后到相应的 Bucket 中查找少量的 Buffer 即可确定。
每个 Buffer 的存放的 Bucket 由 Buffer 的数据块地址（DBA，Data Block Address）运算决
定。在 Bucket 内部，通过 Cache Buffer Chain（它是一个双向链表）将所有的 Buffer 通过 Buffer
Header 信息联系起来。
Buffer Header 存放的是对应数据块的概要信息，包括数据块的文件号、块地址、状态等。
在判断数据块在 Buffer 中是否存在，通过检查 Buffer header 即可确定。
让我们通过一个现实的场景来回顾一下这个过程。
如果大家去过老一点的图书馆，查找过手工索引，你可能记得这样的场景：树立在你面
前的是一排柜子（那是相当的壮观），柜子又被分为很多小的抽屉，抽屉上按照不同的分类方
法标注了相关信息，比如按开头字母顺序，如果我们要查询 Oracle 相关书籍，就需要找到标
记有“O”的抽屉。打开抽屉，我们会看到一系列的卡片，这些卡片通常被一根铁闩串起来（通
常就是一个铁丝），每根卡片上会记录相关书籍的信息，可能包括书籍名称、作者、ISBN 号、
出版日期等，当然这些卡片上还存储了一个重要的信息，就是书籍存放的书架位置信息，有了
这个信息，通过翻阅这些卡片，就可以快速地找到想要的书籍，并且在需要时能够快速从图书
馆浩如烟海的图书中找到我们需要的一本。
在这里，图书馆就是我们的 Buffer Cache，这个 Cache 可能因为“图书数量”的增加而不
断扩大；每个抽屉都是一个 Bucket，这个 Bucket 中存放了根据一定的分类方式（也就是通过
Hash运算）归入的图书信息，也就是 Buffer Header；抽屉中的每张卡片就是一个 Buffer Header，
这些 Buffer Header 上记录了关于数据块的重要信息，如 DBA 等；这些卡片在 Bucket 中，通
过一个铁闩串接起来，这就是 Cache Buffer Chain。
由于每个抽屉只有一根铁闩，如果很多同学都想翻阅这个链上的卡片，那么就产生了
Cache Buffer Chain 的竞争，先来到那个同学持有了 Latch 就能不停的翻阅，其他同学只好不
停的来检查，当然如果检查次数多了（超过了_spin_count），也可以去休息室小憩一会，再来
和其他同学争夺。
从 Oracle 9i 开始,对于 Cache Buffer Chain 的只读访问，其 Latch 可以被共享。也就是说，
如果大家都只是翻一翻卡片，那么大家可以一起读，但是如果有人要借走这本书，那么就只能
书名书名书名书名书名书名书名书名书名书名书名书名书名书名
·10·
独享这个 Latch 了。这就是 Buffer Cache 与 Latch 竞争。
由于 Buffer 根据 Buffer Header 进行散列，最终决定存入那一个 Hash Bucket，那么 Hash
Bucket 的数量在一定程度上决定了每个 Bucket 中 Buffer 数量的多少，也就间接影响了搜索的
性能。所以在不同版本中，Oracle 一直在修改算法，优化 Hash Bucket 的数量。我们可以想象，
Bucket 的数量多一些，那么在同一时间就可以有更多的同学可以拿到不同的抽屉，进行数据
访问；但是更多的抽屉，显然需要更多的存放空间，更多的管理成本，所以优化在什么时候都
不是简单的一元方程。
Hash Bucket 的设置受一个隐含参数_ DB_BLOCK_HASH_BUCKETS 的影响。在 Oracle 7
和 Oracle 8 中，该参数缺省值为 DB_BLOCK_BUFFERS/4 的下一个素数。