GenServer数据库问题处理及Elixir Supervisor最大重启数的影响

1. 超高max_restart配置对系统性能的影响 #

• 彻底失去重启频率限制：Supervisor默认规则是5秒内最多重启5次，你把max_restarts设到亿级后，等于直接取消了频率管控。如果数据库持续不可用，GenServer会进入无限快速重启循环——每次崩溃后立刻被拉起，反复执行init/1里的初始化逻辑（比如尝试连库、加载资源），这会持续消耗CPU、内存，甚至浪费数据库连接配额（比如反复发起连接失败，产生大量TIME_WAIT套接字）。
• 挤占调度器资源：Erlang轻量级进程创建开销低，但架不住高频启停。短时间内大量进程创建销毁会让VM调度器忙于处理进程生命周期，挤占正常业务进程的CPU时间片，导致整个系统响应延迟上升。
• 日志IO压力：频繁崩溃重启会生成大量错误日志，如果日志输出到磁盘，持续的IO写入会成为性能瓶颈，极端情况下可能撑爆磁盘空间。

2. GenServer重启时原有状态数据的去向 #

• 进程崩溃时，所有内部状态会被直接丢弃。每个GenServer都是独立的Erlang进程，状态存储在自身的私有堆和栈中，进程终止后，VM会立即回收这部分内存，状态不会自动传递给新启动的实例。
• 新实例的状态完全取决于init/1的逻辑：如果init是从外部存储（数据库、ETS、文件）加载状态，新实例能拿到最新的外部数据；如果状态是进程内部维护的缓存、计算中间结果，这些数据会彻底丢失，新实例只能从零开始初始化。

3. Elixir垃圾回收与Erlang VM底层机制细节 #

• 进程内存隔离：每个GenServer是独立的轻量级进程，拥有私有堆和栈，与其他进程完全隔离。进程崩溃时，VM无需全局扫描，直接标记该进程的内存为可回收，回收效率极高，不会出现全局GC停顿。
• 崩溃进程的内存回收：进程终止时会触发一次专属GC，彻底清理自身的堆、栈内存。只要没有外部进程持有该进程的引用（比如ETS存了旧PID），不会残留内存泄漏；即便有旧PID引用，后续访问也会直接报错，不会占用有效内存。
• Supervisor重启的底层逻辑：Supervisor本身是个GenServer，通过process_flag(trap_exit, true)监控子进程。子进程崩溃时，Supervisor收到EXIT信号，会对比max_restarts和max_seconds内的重启次数，只要没超限就重启子进程。你设的超高值基本让这个限制失效，会一直尝试重启。
• 轻量级进程的启停开销：Erlang轻量级进程创建仅需几KB内存和少量CPU操作，远低于OS进程，但高频重启仍会累积消耗资源——毕竟每次重启都要执行init逻辑，这部分开销才是性能损耗的核心，而非进程本身的创建销毁。

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