把 Couchbase 当"能自动分片的 MongoDB"来租机器，是这个数据库最贵的一种踩坑方式。它的内存模型跟大多数人脑子里那套"内存越大缓存越多"的直觉完全不同——内存被切成好几个互不相通的池子，Data 有 Data 的配额，Index 有 Index 的配额，Query、FTS、Analytics、Eventing 各自再分一份，一个池子撑死不会匀给另一个池子用。你要是按文档库的老经验，把物理内存一大半划给 Data 服务，那么建索引的时候机器一定卡给你看。这篇不聊概念，只算账：内存怎么分池、配额怎么估、服务什么时候必须拆开、磁盘留多少余量、跨机房复制怎么算带宽，以及六个真实踩过的坑。
大多数文档数据库的内存模型很好理解：内存越大，热数据缓存越多，命中率越高，读就越快。Couchbase 不是这套逻辑。它在集群层面给每个服务设了独立的内存配额，你在节点上把某个服务勾上，就得给这个服务划一块地，这块地被划走之后，剩下的服务一分都拿不到。
具体来说，一个跑满服务的节点上会同时存在这几块：Data 服务拿的是 bucket 内存配额，Index 服务拿的是 索引内存配额，Query、FTS、Analytics、Eventing 各自还有一份自己的配额。这些配额之间不共享、不借调、不动态回收。你在控制台上把 Data 的配额拉到物理内存的八成，Index 服务就算闲着也只能干看着那块内存被 Data 用掉。
这个设计带来的后果很直接：机器"内存没用完"和"服务不卡"是两回事。一台 256GB 的机器，Data 配额给了 200GB，Index 配额给了 16GB，剩下几十 GB 看起来是空闲的，但只要有人的索引超过 16GB，索引就建不起来，或者建到一半被系统拒掉。运维看到的监控是"内存利用率 70%"，实际业务侧是"索引服务报内存不足"——两边对不上账，排查能排查半天。
所以租机器之前第一件事不是挑配置，而是先把内存预算按服务拆开写在纸上：Data 需要多少、Index 需要多少、Query 需要多少、系统和其他服务留多少。拆完再加总，加总出来的数才是你要租的物理内存量。很多团队反过来做——先租一台机器，再往里塞配额——到头来一定是某个服务饿死。
Data 服务这块最容易算错。它跟缓存型数据库的根本差别在于：文档元数据常驻内存，value 可以溢出到磁盘。也就是说，不管你的文档 body 有多大，内存里必须长期住着的是"key + 每文档元数据"，value 只在被访问时进入内存，配额紧张时会被逐出。
算账的起点不是数据总量，是 key 的数量乘以每个 key 的元数据开销。每个文档在内存里除了 key 本身，还要带上若干字节的元数据（含 key 与元数据结构的固定开销），这个开销按官方文档给出的量级估算是几十字节的量级，会随版本、bucket 类型、是否启用某些特性而变化，别拿一个死数字去套所有版本。
举个算账的思路，注意这是典型场景下的估算方法，并不对应任何真实客户的实际数据：假设一个 bucket 里有一亿条文档，key 平均长度三十来字节，加上每文档元数据开销，单条在内存里的常驻成本就是几十字节量级；一亿条乘下来就是几个 GB 的硬性常驻开销。这部分无论如何都省不掉，压缩、落盘、逐出都动不了它。
副本也要一起算进去。Couchbase 的副本是分片级别的副本，一个节点上会同时承载主分片和别的节点的副本分片，所以元数据常驻量要按本机实际承载的分片数（含副本）来算，不是按集群总文档数除以节点数。这一步漏掉副本，是最常见的低估。
元数据常驻之外，剩下的配额才是 value 的活动空间。value 进来、被访问、配额吃紧时按水位线逐出到磁盘。注意，Couchbase 的逐出是有水位线的：配额用到高位水位线附近，系统就开始后台把 value 往磁盘搬；真用到接近满额，前台写入会被限流甚至拒绝。
所以"内存要多大"这个问题的答案不是"数据总量"，而是 元数据常驻量 + 热 value 工作集 + 安全余量。热 value 工作集指的是业务真正频繁访问的那些文档的体积总和，不是全量数据。一个 2TB 的库，如果每天只有 100GB 的内容被反复读写，那 value 工作集就是 100GB 量级，配额给到元数据加上这个数再留余量就够，不必按 2TB 去配内存。
但这里有个陷阱：工作集会漂移。做一次全量扫描、跑一次大范围聚合、来一波批量导出，都可能瞬间把冷数据拉进内存，把热数据挤出去。所以配额里必须留一段缓冲，缓冲的大小取决于你的业务有没有这种"偶发全量"行为。有批量任务的集群，缓冲要给得比纯在线业务的集群厚。
索引服务是 Couchbase 里第二个内存大户，也是最容易在建索引阶段把机器拖死的地方。它有两种存储形态可以选：内存优先型索引（MOI）和 Plasma 存储引擎，两者的取舍是这篇最值得花时间想清楚的决策。
MOI 索引整个驻留在内存里，查询延迟低、吞吐高，适合那种对响应时间有硬性要求的在线检索场景——用户点一下搜索框，几十毫秒内要出结果，这种活儿就该 MOI 干。
代价有两个。一是索引大小受 Index 服务配额硬限制，索引数据加上索引的维护结构超了配额就建不出来，没有任何"溢出到磁盘"的退路。二是重建期内存峰值会翻倍：索引重建（不管是首次建索引、DDL 变更后的重建，还是节点重平衡引起的重建）的过程里，新索引要边建边占内存，旧索引在被替换掉之前还占着内存，两个同时在的时候，内存占用会冲到一个明显高于稳态值的峰值。
这条很要命，因为它意味着 MOI 索引的稳态内存占用不是你要配的上限，峰值才是。配额只按稳态算，重建的时候就会失败或者 OOM。实操里普遍的做法是给 Index 配额留出足以容纳重建峰值的余量，具体倍数看索引的重建策略和并发重建的索引数量，不是一句话能定的，按官方文档给出的量级估算去做，别拍脑袋。
Plasma 是 Couchbase 新一代索引存储引擎，索引主体可以落在磁盘上，内存里放的是缓冲和常驻结构。代价是查询延迟上升——同样一个索引查询，走磁盘和走内存不是一个量级的延迟——好处是索引大小不再被内存配额卡死，TB 级的索引也能建。
判断标准其实很清楚：走 MOI 的条件是你的热索引能完整装进内存，并且查询延迟是业务的硬指标；必须 Plasma 的条件是索引体积明显超过你能给的内存、或者这些索引是冷索引（历史数据查询、后台分析、运营偶尔查一次）。还有种折中走法：热索引用 MOI，冷索引用 Plasma，两边放在不同的 Index 节点上，各按各的资源画像配机器。
混着放同一台机器上是我不太推荐的做法。MOI 和 Plasma 混在一台 Index 节点上，内存配额是共用的，Plasma 的缓冲会挤占 MOI 的可用空间，而且重建期两边一起冲峰值，风险叠加。
N1QL 是 Couchbase 的 SQL 方言，Query 服务负责解析、生成计划、执行。这一段很多人低估了，以为查询嘛，主要靠 Data 节点读数据。实际上 Query 服务是 CPU 和内存一起吃：解析和计划生成吃 CPU，排序、哈希 JOIN、聚合、去重这些算子要在内存里攒数据结构，攒不下就往临时空间落盘。
一条不带 ORDER BY、不带 JOIN 的单键查询，成本很低，查得到就返回。真正烧资源的是这三类：一是 ORDER BY 一个大结果集，排序要在内存里攒下待排序的数据；二是 JOIN，尤其是哈希 JOIN，要在内存里建哈希表，被驱动表越大哈希表越大；三是 GROUP BY 加大基数聚合，聚合的中间状态全在内存里。
结果集超出可用内存时，Query 服务会把中间结果写到临时空间目录。这个目录在磁盘上，所以 Query 节点也需要一块能扛住写的盘，不是随便给个系统盘就行。临时空间写爆了，查询直接失败，不是降级。
Query 和 Data 混布是最容易出事的搭法。Data 服务在读盘、在 compaction、在做逐出，Query 服务在排序、在建哈希表，两边抢的是同一份内存和同一份 IO。表现是：平时都正常，一到业务高峰或者索引重建窗口，查询延迟整体飘上去，而且飘得跟 CPU、内存监控都不完全对得上——因为瓶颈在两边互相打断。
Query 节点还有一个容易被忽略的限制项：结果集大小要设上限。不设的话，一条写坏的 N1QL（比如漏了 LIMIT 又带 JOIN）能把整台 Query 节点的内存吃干。这不是理论风险，是运维群里最常见的那种"一条 SQL 把集群干趴"的事故。给 Query 服务设合理的请求上限和超时，比事后救火划算得多。
Couchbase 允许一台节点同时跑多个服务，最小三节点的集群也能把 Data、Index、Query 全塞进去。开发环境这么干完全没问题，生产环境这么干是拿稳定性换预算。
三节点混布的典型症状是"周期性抖动"。Data 的 compaction 在后台吃 IO，同一台机器上的 Index 服务在写索引，Query 服务在排序，三者叠在一起，磁盘队列深度一上来，所有服务的延迟一起涨。更麻烦的是内存：三个服务的配额在一台机器上互相挤压，总配额看着没超，单个服务早就不够了。
还有一个只有混布才会遇到的麻烦：故障域重合。三节点各跑全服务，挂一台等于同时损失三分之一的 Data、三分之一的 Index、三分之一的 Query。如果索引的副本数不够，挂一台就是部分索引不可用，跟拆分部署相比，可用性的算术完全不一样。
所以判断标准不是"机器够不够"，是"这台机器上有没有两个服务会在同一时间抢同一类资源"。Data 和 Index 抢内存和 IO，Query 和 Data 抢内存和 IO，Index 重建和 Data 的 compaction 抢 IO。只要有任一组合的峰值会撞在一起，就该拆。
我给的判断线是这三条，命中任意一条就别再混了：一是 索引总大小接近或超过单节点能给 Index 的内存；二是 用 MOI 索引且索引数量多，重建期峰值叠加的风险高；三是 业务有明确的大批量写入窗口，比如每天凌晨灌数据，灌的同时索引在追，两个 IO 大户撞一起。
Query 服务拆不拆，看查询复杂度。纯单键 get/set 的业务，Query 基本闲着，混在 Data 上没问题。有复杂 N1QL、有 JOIN、有聚合的业务，Query 单独出机是划算的——Query 节点配置要求跟 Data 节点不一样，单独出机反而省钱。
拆开的好处是每台机器可以按角色画像配，不再用一台"啥都够"的高配机去覆盖所有角色。三个角色的画像差别很大：
Data 节点要的是大内存加 NVMe。内存的用途前面算过了，元数据常驻加热 value 工作集；磁盘这边 Data 的写路径是 append-only 再加 compaction，随机写和顺序写都重，NVMe 是硬要求，SATA 盘在 compaction 窗口会拖出明显的延迟毛刺。
Index 节点要的是更大的内存、磁盘可以普通。注意这个反差：Index 服务如果是 MOI，索引全在内存，磁盘只放索引的持久化和恢复用数据，用企业级 SATA SSD 或者普通 NVMe 都行，重点是内存要给够——包括重建峰值的那部分。如果是 Plasma，磁盘容量和 IO 都要跟上，但内存可以按缓冲需求配，比 MOI 低。
Query 节点要的是 CPU 核数和中等内存，加一块能写的小容量 NVMe 放临时空间。Query 节点不存数据，磁盘容量需求小，但临时空间的写入要扛得住，别给个读写性能很弱的系统盘了事。
Couchbase 的写路径不原地改数据。文档更新是追加写新版本，旧版本留在文件里，等后台的 compaction 来回收。这个设计的好处是写延迟稳定、崩溃恢复简单，代价是磁盘会持续产生碎片空间。
compaction 是后台的 IO 大户，它会把有效数据读出来重写到一个新文件，写完之后再切换。这个过程中磁盘要同时容纳旧文件和新文件，所以 磁盘必须留足余量。行业里通行的做法是别把盘用到 80% 以上——这不是一个精确的技术阈值，而是一个运维安全线：留出的空间能容纳一次 compaction 的临时膨胀，也能扛住写入高峰。
盘用到 90% 以上会发生什么？先是 compaction 跑不起来（没空间写新文件），然后碎片越积越多，然后写入因为磁盘满被拒。这个过程是有延迟的——不是今天用到 90% 明天就挂，而是某次大写入叠上 compaction，几个小时内水位线一路顶到 100%，然后业务开始报错。等到磁盘满了才想起来清，往往已经没法在线做了。
自动 compaction 的触发阈值要单独调。默认设置是按碎片率触发的，在写入平稳的场景下够用；高写入场景下默认阈值追不上碎片产生的速度，compaction 永远落后于写入，磁盘水位线缓慢但持续地上涨。这时的做法是调低碎片触发阈值，并把 compaction 的时间窗口错开业务高峰——让它在凌晨跑，而不是跟业务抢 IO。
NVMe 这边还要算一笔寿命账。append-only 加 compaction 意味着写放大是实打实的：一次文档更新至少写一次新版本，compaction 再把有效数据整体重写一遍，实际写到盘上的数据量远大于业务侧的逻辑写入量。选盘的时候要看 DWPD（每日整盘写入次数）和 TBW 总写入量，别只看容量。消费级 NVMe 在持续高写入的 Couchbase 节点上，寿命消耗会超出预期。
XDCR（跨数据中心复制）是把一个集群的变更持续推到另一个集群的机制。它的开销是出网带宽加 CPU 两笔账，很多人只算了第一笔。
带宽账的算法是：每秒变更文档数 × 平均文档大小 × 协议开销系数 × 复制链路数。注意算的是"变更"不是"全量"，所以要看你的写入/更新速率，不是数据总量。一个大字段文档被频繁更新的集群，XDCR 带宽能吃得很凶；反过来，写入少、读多的集群，XDCR 很轻。双向复制要把两个方向都算上，单向复制只算一个方向。
CPU 账来自压缩、序列化、冲突判断和元数据比较。复制不是简单地把文档字节流丢过去，源端要挑出变更、判断冲突、序列化、可选压缩，目标端要反解、写盘、更新索引。这意味着 开启 XDCR 之后，源集群和目标集群的 CPU 和磁盘写都会上升，不只是网络。
冲突解决策略会影响写入放大。默认的基于修订信息的冲突判定是轻量的，但如果你启用了基于时间戳或者自定义字段的冲突解决，源端在判定之前可能需要额外读取文档的元数据和属性，判定过程本身变成了一次额外的读。自定义冲突解决逻辑越复杂，复制侧的额外读放大越明显，这部分要算进源集群的 IO 预算里。
带宽选型上还有个实操建议：复制链路的带宽要按峰值算，不是按均值算。日间写入高峰叠上批量灌数据，变更速率可能是均值的几倍。带宽按均值买，高峰时复制队列开始积压，积压到一定程度会触发限流甚至暂停；而积压清完之前，目标集群的数据新鲜度是掉队的。
下面是按服务角色拆开之后的对照表，横向看的是每个角色主要吃哪种资源、内存配额怎么定、磁盘有什么要求、以及最容易踩的那个坑。数字口径一律按"量级估算"理解，具体到版本和集群规模会变。
| 服务角色 | 主要吃哪种资源 | 内存配额怎么定 | 磁盘要求 | 典型踩坑 |
|---|---|---|---|---|
| Data | 内存（元数据常驻 + value 工作集）、磁盘 IO、网络 | 按 key 数 × 每文档元数据开销（按官方文档给出的量级估算）算常驻量，再加热 value 工作集与副本分片，留安全余量 | NVMe，容量按 append-only 与 compaction 膨胀留余量，使用率控制在 80% 以下 | 配额按数据总量给，忽略了 key 数和副本 |
| Index | 内存（MOI 尤甚）、索引重建期磁盘 IO | MOI 按索引稳态 + 重建峰值来定；Plasma 按缓冲与常驻结构定，容量交给磁盘 | MOI 用普通企业级 SSD 即可；Plasma 需要容量与 IO 兼顾的 NVMe | 只按稳态配内存，重建期打满配额导致索引失败 |
| Query | CPU（解析与执行）、内存（排序 JOIN 聚合）、临时空间写 | 按并发查询数 × 单查询中间结果量估算，并设结果集上限与超时兜底 | 小容量 NVMe 放临时空间，容量需求不高但写入要扛得住 | 不设结果集上限，一条 SQL 吃干节点内存 |
| FTS（全文检索） | 内存（倒排索引）、磁盘 IO、CPU（分词与分析） | 按倒排索引规模与分词器复杂度估，索引分区后按分区分摊 | NVMe 优先，分词与索引写入较密集 | FTS 与 Data 混布，索引构建期 IO 抢占影响写入 |
| Analytics / Eventing | 内存与 CPU 双高，独立执行引擎 | 独立配额，建议单独出机，不要与 Data、Index 争 | 大容量 NVMe，中间结果落盘频繁 | 与在线服务同机部署，分析任务拖慢在线查询 |
| 三节点全服务混布 | 内存、磁盘 IO、CPU 全部叠加，故障域重合 | 三个服务配额互不相通，总内存看着够不代表单个服务够 | compaction 与索引写入抢同一块盘的 IO | 挂一台同时损失三类服务能力 |
为什么坑：Couchbase 跑在操作系统之上，磁盘文件的读写要走 OS 页缓存。配额给到物理内存的八成以上，剩下的内存不够页缓存用，value 的磁盘读取就变成大量的真实磁盘 IO，延迟直接上一个台阶。表现出来是"内存配额明明还有富余，读延迟却上去了"。更极端的情况是同机上还有其他进程（监控 agent、日志采集、备份工具），系统层面开始用 swap，整机抖动。
怎么避：给操作系统和其他进程留出固定份额，Data 配额不要按物理内存的绝大部分去设，剩下的部分留给页缓存和系统进程。部署完用监控确认 swap 长期为零、页缓存有稳定占用，再上线。同一台机器上再塞别的吃内存的服务，也要一并算进这份预算。
为什么坑：默认的碎片触发阈值是按一般写入强度设计的。写入密集的集群里，新碎片产生的速度超过 compaction 回收的速度，磁盘水位线缓慢但持续上涨，等到某天叠上大批量写入，盘就满了。这类事故的特征是"很久没事，一出事就是大事"。
怎么避：按实际写入强度调低碎片触发阈值，把 compaction 的时间窗口挪到业务低峰，并且给磁盘水位线设两级告警——一级提醒，一级阻断。水位线告警比碎片率告警更直观，也更接近"会不会出事"这个本质问题。
为什么坑：MOI 索引全内存，重建期峰值能冲到稳态之上；Data 服务同时在跑 compaction 和读写。内存这边两个配额互相挤压，IO 这边两个大户同时抢盘，结果是索引重建失败或者重建窗口内写入延迟暴涨。这个坑在开发机上往往不出现，因为开发机数据量小、重建快、没有并发写入。
怎么避：用 MOI 就把 Index 单独出机，内存按重建峰值配；实在要混布，就把索引拆小、拆成分区索引，让单次重建的内存峰值可控，并且把重建安排在没有批量写入的窗口。
为什么坑：一条没写 LIMIT 又带 JOIN 的 N1QL，中间结果能撑到几十 GB。Query 节点没有上限保护的话，这条语句会一路吃内存，轻则单查询失败，重则节点被系统杀掉，连带这台节点上的其他服务一起遭殃。
怎么避：三个动作一起做——给 Query 服务设结果集大小和并发数上限，设查询超时，以及在应用侧强制所有 N1QL 带 LIMIT。第三件事是根本，前两件是兜底。临时空间目录也要单独放在有足够容量和性能的盘上，别放在系统盘。
为什么坑：变更速率是波动的，批量灌数据的时候能到平时的好几倍。带宽按均值买，高峰期复制队列积压，目标集群读到的就是过时数据。而依赖目标集群做读写分离或者灾备的业务，这时候读出来的数据是错误的，比"复制慢一点"严重得多。
怎么避：带宽按峰值变更速率算，不是按日均。监控上盯复制队列的深度而不是只看带宽利用率——队列持续变长就是带宽不够的信号，这个指标比带宽百分比更早报警。开启 XDCR 的同时也要把源端和目标端的 CPU 与磁盘写预算算进去。
为什么坑：append-only 写加 compaction 重写，实际落到盘上的数据量远大于业务侧的逻辑写入量。只看容量挑的盘，DWPD 和 TBW 指标可能撑不住这个写入强度，用一段时间之后性能下降、寿命告警。
怎么避：按"逻辑写入量乘以写放大系数"估算每日实际写入量，再对照盘的 DWPD 和 TBW 选型。写入密集的 Data 节点优先选高耐久的企业级 NVMe，并且把磁盘 SMART 的健康度纳入常规监控，不要等盘掉速了才发现。
把前面这些账算完，选型思路就很清楚了：先拆服务，再按角色配机器，之后算总量。三个角色的硬件画像差别很大，硬要用一台"什么都够"的高配机覆盖，结果是每个角色都有一半资源闲置，总价还更贵。
落地顺序我建议这么走：先估 Data 的元数据常驻量和热工作集，定下 Data 节点的内存和 NVMe；再估索引的形态（MOI 还是 Plasma）和重建峰值，定下 Index 节点的内存；然后按查询复杂度定 Query 节点的 CPU 核数和临时空间；随后把磁盘余量、compaction 窗口、XDCR 带宽这三件事单独过一遍，确认没有哪台机器会成为瓶颈。
服务器配置参考这块，我一般会让客户把三种角色的配置需求列清楚，再去找能按角色分别出机的服务商。一万网络深耕 IDC 19 年（成立于 2007 年），可以按 Data、Index、Query 三种角色分别出机，不用被迫拿同一套配置去套三个完全不同的资源画像；深圳自营机柜，最快 1 分钟上架，扩容加节点的时候不用等一周；7×24 中文工单，平均 5 分钟响应，索引重建卡住这种事能及时找到人。价格这块需实时询价，价格主要受 CPU、内存、存储、带宽和 IP 影响——内存容量和 NVMe 的耐久等级在这个场景里是主要变量，询价时把这两项说清楚，报价才有参考价值。
技术上能起，但我不建议。单节点意味着没有副本分片，节点故障就是数据不可用，恢复只能靠备份；服务混布在一台上，compaction、索引重建、查询排序抢的是同一份内存和 IO，高峰期延迟不可控。真要跑，也只适合内部工具、数据量小、能接受停机的场景。生产环境的最低配置我一般按三节点起算，并且把副本数配上，让单节点故障不至于变成数据丢失。
没有放之四海皆准的比例，但有算法：先算元数据常驻量（key 数乘每文档元数据开销，按官方文档给出的量级估算，含副本分片），再加热 value 工作集，再加安全余量。这个数算出来之后，还要跟"物理内存减去系统和页缓存所需"这个上限对一遍，取两者里更小的那个。实践中常见的错误是跳过第一步，直接按物理内存的某个比例拍一个数——key 数多、单文档小的库，按容量比例拍出来的配额一定不够。
看三条：索引总大小是不是接近或超过单节点能给 Index 的内存、是不是用了 MOI 且索引数量多、有没有大批量写入窗口和索引维护撞在一起。命中任意一条就该拆。反过来说，如果索引很小、用的 Plasma、写入平稳，混在 Data 节点上问题不大，省一台机器的预算是合理的。判断依据是"两个服务的资源峰值会不会撞在同一时间窗"，不是"机器性能够不够"。
会，而且是温和地跑满——不是一天之内涨上去，而是碎片产生速度快于回收速度，水位线缓慢上涨，某次大写入叠上来就顶到 100%。盘一满，写入被拒，业务开始报错。预防的办法是调低碎片触发阈值、把 compaction 排到低峰、给磁盘水位线设两级告警，并且始终让使用率保持在 80% 以下，给 compaction 的临时膨胀留出空间。
按变更速率算，不按数据总量算：每秒变更文档数 × 平均文档大小 × 协议开销系数 × 复制链路数，双向复制算两个方向。关键是要按峰值算不是按日均——批量灌数据的时段，变更速率可能是平时的数倍。监控上盯复制队列深度，队列持续变长就是带宽不够的早期信号，比带宽利用率百分比更早反映问题。也别忘了源端和目标端的 CPU 与磁盘写也会上升。
取决于数据量、节点间的网络吞吐、以及磁盘能不能扛住重平衡期间的额外读写。重平衡做的是分片迁移，迁移期间 Data 的读写还在继续，compaction 也在跑，三者叠在一起，实际耗时往往比"数据量除以带宽"算出来的长。扩容前先确认磁盘余量够，重平衡期间索引也会重建，Index 节点的内存峰值要提前留好；把重平衡窗口安排在业务低峰，并且限速跑，避免把在线流量挤掉。
先判断不够的是哪个池子。如果是某个服务自己的配额不够（比如 Index 配额打满但整机内存还有富余），加内存解决不了问题——你得先去调配额分配，或者把这个服务拆出去。如果是所有配额都算过了确实不够，才是加物理内存。我见过太多"内存告警就加内存"的案子，加完之后问题依旧，因为真正的问题是配额划错了或者服务没拆开。先拆账，再决定要不要花钱。
核心是承认"重建期新索引和旧索引会同时占内存"这件事，配额不能只按稳态算。具体倍数取决于索引的重建策略和同时重建的索引数量，按官方文档给出的量级估算去做规划，别拍脑袋定。降低风险的办法有三个：把大索引拆成分区索引，让单次重建的峰值可控；重建错峰，别让多个大索引同时重建；以及给 Index 服务的内存占用设告警线，在峰值到来之前就能看到趋势。
问到底还是那个算法：元数据常驻量加 value 工作集加安全余量，得出的配额再和"物理内存减去系统所需的部分"对一遍，取小的那个。页缓存不是可以随便牺牲的东西——Data 服务的 value 从磁盘读回来要走页缓存，页缓存被挤掉之后，读放大立刻体现在延迟上，而且这种延迟升高在内存监控上看不出来，很容易误判成"磁盘慢了"。
一句话记住：Couchbase 的内存是分池的，池子之间不通，池子之外还要给操作系统留一份。按这个原则算出来的机器配置，比"买个大内存的机器再说"省得多，也稳得多。
本文涉及的每文档元数据开销、索引存储形态（MOI 与 Plasma）的行为差异、配额分池机制、compaction 与磁盘余量口径，均以 Couchbase 官方文档给出的说明为核对基准，按"量级估算"的口径使用，未编造精确数值；版本差异会导致具体数值变化，落地前请以你所用版本的官方文档为准。文中出现的配置思路与场景描述均为典型部署思路，并非特指某一真实客户，未使用任何实测数据。
服务器配置与租用相关的信息，可参考一万网络官网 https://www.idc10000.net/ 的产品页面与配置说明，具体配置方案、交付周期（含最快 1 分钟上架的服务能力）与支持方式以官网页面的实时说明为准。文中提及的价格口径为「需实时询价，价格主要受 CPU、内存、存储、带宽和 IP 影响」，未给出任何具体数字报价，具体以签约时最新报价与合同为准。
上一篇：2026 Discourse 自建社区论坛服务器租用干货：PostgreSQL 与 Sidekiq 队列配置大全
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
