向Mnesia表写入数百万记录内存占用高 删除后无法自动回收

Mnesia内存未回收问题排查建议 #

1. 确认Mnesia内置进程的垃圾回收触发逻辑 #

• Mnesia的mnesia_tm事务管理进程、表对应的存储进程默认不会主动触发频繁GC，尤其在处理大量写入删除操作时，进程堆里残留的旧数据、引用的全局binary会长期留存。你可以先执行mnesia:system_info(info)查看所有Mnesia相关进程的PID，单独对这些进程执行GC测试，确认内存下降幅度，判断是否是Mnesia内部进程持有内存。

2. 检查脏删除操作的内存开销逻辑 #

• 你使用dirty_delete类操作删除ordered_set类型的disk_copies表时，Mnesia会先加载待删除记录的索引片段到内存处理，批量删除200万条记录时会临时生成大量进程堆数据和引用计数binary，这些binary属于全局堆，只有当所有引用它的进程都完成GC后才会释放。你可以调整删除逻辑为批量分批删除+每批次执行后主动对Mnesia表进程触发GC，避免内存峰值过高。

3. 验证disk_copies表的内存缓存配置 #

• disk_copies表默认会在内存中缓存最近访问的记录和索引数据，即使记录被删除，缓存的页数据不会主动立即淘汰。你可以通过mnesia:change_table_copy_type/3临时把测试表转为disc_only_copies做对照测试，如果内存涨幅明显下降，说明是disk_copies的内存缓存占用了大部分空间，可通过调整{dump_log_load_threshold, N}、{dump_log_time_threshold, Ms}参数降低内存缓存的留存时间。

4. 核查事务写入的残留引用 #

• 你用事务写入数据时，事务上下文会临时持有记录的binary引用，如果事务提交后对应的事务管理进程没有及时GC，这些引用会一直留存。你可以把写入操作换成脏写入做对照测试，如果测试后binary占用明显下降，说明是事务上下文残留引用导致的内存占用，可设置事务批量提交的阈值，每完成一定数量的事务后主动触发mnesia_tm进程的GC。

5. 调整Erlang虚拟机的GC参数 #

• 可以在启动beam时添加+M true +MMscs 16384参数调整全局binary堆的GC阈值，或者添加+G true启用更激进的GC策略，测试调整后内存自动回收的情况是否符合预期。

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