将MongoDB的_tmp目录移至RAM磁盘：性能提升效果与利弊限制

先直接给结论：是否能带来显著性能提升，完全取决于你的实际工作负载——如果你的MongoDB经常处理超100MB的聚合任务、频繁创建大索引这类依赖_tmp目录的IO密集型操作，那把_tmp移到RAM磁盘（比如Linux的tmpfs）确实能带来非常明显的性能提升；但如果这类操作很少，那基本感受不到变化，甚至可能得不偿失。

为什么能提升性能？ #

MongoDB的_tmp目录是用来存放聚合、索引创建等操作的临时数据的，这些操作往往是磁盘IO密集型的——机械盘的读写延迟动辄几毫秒，哪怕是普通SSD也要几十微秒，而RAM磁盘的读写延迟是微秒级别的，相当于把临时数据的读写速度提升了几十到上百倍。如果你的任务刚好卡在磁盘IO瓶颈上，那完成时间会大幅缩短，比如原本要跑几分钟的大聚合，可能几十秒就搞定了。

但这个方案的弊端和限制也不少，一定要提前考虑： #

• 内存容量硬限制：RAM磁盘的大小直接受限于物理内存，一旦_tmp里的临时数据超过了RAM磁盘的容量，MongoDB会直接抛出空间不足的错误，当前任务直接失败。更头疼的是，分配给RAM磁盘的内存是独占的，这部分内存没法再给MongoDB的WiredTiger缓存用——如果你的内存本来就不算充裕，可能会导致常规查询的缓存命中率下降，反而拖慢整体性能。
• 断电即失的风险：RAM磁盘里的所有数据断电就会消失。如果MongoDB正在执行依赖_tmp的任务时突然断电，不仅当前任务会中断，而且没有办法恢复之前的进度，只能从头再来。虽然_tmp里的是临时数据，不会影响核心数据的一致性，但任务中断带来的时间成本也是要考虑的。
• 配置和维护成本：你得先在系统层面创建并挂载RAM磁盘（比如Linux下用mount -t tmpfs -o size=10G tmpfs /path/to/ram_tmp），然后修改MongoDB配置文件里的storage.tmpPath参数指向这个新目录，还要确保MongoDB进程有该目录的读写权限。另外，系统重启后RAM磁盘会被清空，你得配置自动挂载脚本；平时还要监控RAM磁盘的使用率，防止突然占满导致任务失败。
• SSD环境下收益递减：现在很多生产环境已经用上了NVMe SSD，它的随机读写速度已经非常接近内存了。如果你的MongoDB已经部署在NVMe SSD上，那把_tmp移到RAM磁盘的性能提升会非常有限，反而占用内存的代价会更突出。
• 多实例冲突问题：如果同一台机器上跑了多个MongoDB实例，都把_tmp指向同一个RAM磁盘，那它们会互相抢占空间，很容易出现某个实例的任务因为空间不足而失败的情况，管理起来会很麻烦。

最后给个小建议 #

如果你的工作负载确实有大量的大_tmp操作，而且服务器有足够的富余内存，那可以尝试这个方案，但一定要做好容量规划和监控；如果是普通的业务负载，用高性能SSD就完全足够了，没必要折腾RAM磁盘。

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