为何64GB内存CockroachDB集群性能不及32GB内存集群？

• 内存参数未适配导致资源浪费或额外开销
  CockroachDB的核心内存参数（如--cache、--sql-memory-pool-size）默认按节点总内存的固定比例分配。若未针对64GB节点调整这些参数，额外内存可能并未有效用于缓存或查询执行，反而因内存空间过大引发更频繁的垃圾回收（GC）扫描，或操作系统层面的内存页碎片化，增加CPU消耗。比如数据集远小于32GB节点的缓存容量时，64GB节点的冗余缓存空间会带来不必要的内存管理开销。

• 查询执行计划的不合理选择
  即使查询语句完全相同，CockroachDB的优化器会根据节点资源生成不同执行计划。64GB节点可能因内存充足，选择了在当前负载下效率更低的计划：比如对小数据集使用内存哈希Join，其构建与探测的CPU开销反而高于排序合并Join；或优化器错误预估数据分布，触发不必要的数据跨节点重分布，增加网络延迟。

• CPU/磁盘IO瓶颈掩盖内存优势
  若测试负载受限于CPU计算能力或磁盘IO性能（如冷数据查询、批量写入），且两组集群的CPU、磁盘配置一致，64GB内存的缓存优势无法发挥作用。极端情况下，64GB节点的缓存可能容纳更多冷数据，导致热点数据被挤出缓存，反而增加磁盘IO次数，拉低整体性能。

• 并发调度与事务冲突的额外开销
  高内存节点默认允许更多的并发SQL执行线程，若测试并发量未匹配提升，过多的线程会引发CPU调度竞争，降低单查询执行效率。此外，分布式事务的锁策略可能因内存配置变化出现调整，比如更长的锁持有时间，导致事务冲突等待增加，拖累整体吞吐量。

• 集群数据分布或初始化差异
  两组集群的副本分布、分区策略或索引设置可能存在细微差异：比如64GB集群的副本分布不均，部分节点承担了远超平均的负载；或索引未针对查询模式优化，导致查询需要扫描更多数据，抵消了内存优势。

• 操作系统内存管理配置差异
  Linux系统的内存相关参数（如vm.swappiness、transparent_hugepage）若未统一配置，可能影响64GB节点性能：比如透明大页开启导致内存分配延迟，或swappiness过高使系统过早使用交换分区，引发磁盘IO型性能下降。

内容的提问来源于stack exchange，提问作者Shweta