RethinkDB在i3.Metal实例遇写入瓶颈：仅达1.5k次/秒

我来分享下针对你这个场景的优化思路和替代选项——毕竟我之前也折腾过RethinkDB在云环境的性能调优，踩过不少坑：

1. 存储层针对性调优 #

i3.metal的8块NVMe RAID0硬件潜力很大，但RethinkDB默认配置可能没跟上：

• 调整缓存大小：i3.metal内存充足（通常256GB），把RethinkDB的cache_size设为总内存的70%左右，让更多热数据留在内存里，减少磁盘IO。执行命令：

  r.db('rethinkdb').table('config').get('server').update({cache_size: 188743680}) // 对应180GB，可根据实际内存调整
  

• 优化磁盘挂载参数：确保RethinkDB数据目录挂载的RAID卷添加了noatime参数，禁用文件访问时间记录，减少不必要的磁盘写入。
• RAID条带对齐：检查RAID0的条带大小是否匹配NVMe的物理块大小（通常4K/8K），建议设为64K或128K，避免IO对齐损耗。

2. Changefeed瓶颈专项优化 #

你的场景中Changefeed是核心性能卡点，试试这些调整：

• 增大Changefeed队列容量：默认队列大小可能太小，导致写入压力上来时队列溢出、延迟飙升。调大队列：

  r.table('your_target_table').config().update({changefeed_queue_size: 10000})
  

• 启用批量推送模式：把实时单条推送改成批量推送，减少网络交互和服务器端处理开销。客户端订阅时用：

  r.table('your_target_table').changes({batch: true, batch_size: 100, timeout: 100})
  

• 优化客户端消费逻辑：检查2个订阅客户端是否存在同步阻塞处理的情况——如果客户端单线程处理每个变更，很容易导致队列积压。建议用异步/多线程消费，避免拖慢服务器端推送速度。

3. 服务器端全局配置调优 #

• 提升并发查询上限：i3.metal核数充足（36vCPU），默认的max_concurrent_queries可能限制了并发处理能力，调大到200+：

  r.db('rethinkdb').table('config').get('server').update({max_concurrent_queries: 200})
  

• 开启Direct IO：对于NVMe磁盘，开启direct_io可以绕过操作系统缓存，减少IO层的额外开销：

  r.db('rethinkdb').table('config').get('server').update({direct_io: true})
  

• 降低日志级别：把日志级别从info改成warning，减少磁盘日志写入的性能消耗。

4. 网络层优化 #

确保客户端和i3.metal实例在同一个VPC内，使用私有IP通信，避免公网延迟。另外，检查EC2实例的网络带宽是否跑满（i3.metal支持10Gbps），如果是网络瓶颈，可以给客户端开启TCP_NODELAY选项，减少TCP传输的延迟。

如果调整配置后还是达不到预期，这些云环境可能更适合RethinkDB：

• 谷歌云n2d/c3d-metal实例：谷歌云的裸金属实例NVMe性能强劲，且跨实例网络延迟更低，对于Changefeed这种需要低延迟推送的场景更友好；也可以选择高IOPS的Persistent SSD，不用手动折腾RAID。
• 阿里云g8i裸金属实例：阿里云的存储栈针对数据库场景做过优化，NVMe SSD的IO调度和性能表现更适配RethinkDB的存储引擎。
• 托管RethinkDB服务：比如ScaleGrid这类第三方托管服务，会帮你预优化硬件配置、存储参数和网络设置，省去自己调优的成本。

最后补充一点：你提到的低配置8k写/秒基准，大概率是纯写入无Changefeed的场景——Changefeed本身会带来额外的写入同步、队列存储和网络推送开销，所以带订阅的性能肯定会低于纯写入。建议先单独测试单订阅者的性能，再逐步增加，定位瓶颈是在服务器推送还是客户端消费。

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