小内存服务器跑比特币节点：dbcache、par 与连接数的减配清单

默认内存是怎么定出来的

比特币核心的内存大头之一是 UTXO 数据库缓存，参数 -dbcache，单位 MiB。按主分支文档当前口径：在检测到系统内存不少于 4 GiB 的机器上默认 1024，低于 4 GiB 的机器默认 450，参数下限是 4；更早版本文档则一律按 450 描述，版本不同要以本机帮助为准。缓存大的好处在同步阶段最明显：校验区块要读写 UTXO 集合，缓存够大，磁盘随机读写就少，追链快。小内存机器的现实是反过来的——与其和缓存争内存导致系统频繁换页，不如主动把缓存调小。文档的判断标准很实用：如果运行期间观察到持续的换页 I/O，就用更低的 -dbcache 重启；还不够，再考虑减 -maxmempool、减 -maxconnections，极端情况用 -blocksonly。反过来，节点启动时若发现 -dbcache 明显大于内存承受能力，也会给出提示，别无视它。

逐项减配的代价

-dbcache 调小的代价是同步变慢，同步完成之后影响会明显减弱，除非你在做对验证时延敏感的挖矿类工作。-par 是脚本验证线程数，默认是核心数减一，在低配机器上减到 1 能降低并发压力，代价同样集中在同步阶段。-maxconnections 是自动连接总数上限，默认值随版本而异（较新版本源码与主分支文档给的是 200，更早版本如 29.x 时代的文档与源码给的是 125，以本机启动帮助为准），每条活跃连接都吃资源，缩到几十能省下不少；addnode 类手动连接另有上限 8，不计入这个池子的概念要分清。-blocksonly 是终极大闸：节点不再接收和转发交易（例外是白名单类中继权限的对等和区块内自带的交易），内存池功能基本关掉，文档给出的默认内存占用可以降到个位数 MiB 的量级。代价是节点不再帮你发现零确认交易、也失去了参与交易relay 的网络贡献，只剩区块验证这一个核心功能。

一条务实的配置路径

第一步先按默认跑：如果机器内存不低于 4 GiB，默认配置本来就是平衡的，别急着调。第二步只动一个参数：看到持续换页再降 -dbcache，每次降幅温和（例如四分之一到三分之一），每次重启观察。第三步动连接数与线程数。第四步才考虑 -blocksonly——这一步之前先问清楚：这台节点是不是需要处理交易相关功能（收付款通知、费率估算、零确认提示都会受影响）。第五步，所有调整都不是永久决定：同步完成、内存压力过去之后，可以回到更宽松的默认值重启一次。

别忘了的隐性账

小内存机器上，比参数更重要的是别把节点和别的重负载进程挤同一台机器；数据库缓存、内存池、连接开销和页面缓存会互相抢地盘。同步期间用日志与系统工具观察：内存不足的表现通常是慢而不是崩，这让它很容易被忽视。减配的原则只有一句话：用功能换稳定，用可观察的换页与同步时长做判断依据，而不是抄别人的参数表。本文不构成投资建议。

除了四个参数之外的两笔账

参数之外还有两个对小内存机器影响真实的因素。一是磁盘：小内存 VPS 常配慢速 SSD 或网络盘，节点同步阶段大量随机读写，磁盘慢会先于内存成为瓶颈，表现为同步极慢但 CPU 和内存都不高——此时再调参数也挤不出性能，升级磁盘类型或给系统页缓存留更多余量才是解法。二是同步策略：首次同步可以选择跳过历史区块的完整脚本校验（通过链尖假设类机制），这在几乎所有配置下都显著更快，但意味着你把一部分信任从”逐块自己验”换成了”信任软件内置假设”；小内存机器尤其不要在慢速磁盘上对每个历史区块重跑全量验签，那会把资源问题放大成以周计的等待。把”内存—磁盘—同步策略”三件事一起看，才能解释为什么两台同样标称 2G 内存的机器，同步时长可以差出一个数量级。参数表能给你的只是一个起点，真正的调优是对瓶颈的持续观察。