asciinema-server内存泄漏问题分析与解决方案

问题现象

asciinema-server项目在v20231217版本中出现了一个严重的内存泄漏问题。多位用户报告称，即使在极低负载（每天仅几个请求）的情况下，beam.smp进程的内存使用量会持续增长，最终导致系统触发OOM Killer机制终止进程。

从用户提供的监控图表可以清晰地看到，内存使用呈现线性增长趋势，每2-3天就会耗尽系统内存。这一问题在1GB内存的小型VPS上尤为明显，严重影响了服务的稳定性。

问题根源

经过项目维护者的深入调查，最终确定内存泄漏的根源在于内置的Prometheus指标收集端点。该端点默认监听在9568端口，用于收集和暴露BEAM VM的各种性能指标，包括：

• 内存使用情况
• CPU使用率
• HTTP请求统计
• 数据库查询统计
• 后台作业统计

问题出在telemetry_metrics_prometheus_core库的实现上：当这些指标数据未被定期查询时，系统会持续在ETS表中累积聚合数据，而不会自动清理。这与一个已知的库实现问题相符。

技术分析

Prometheus指标收集端点的设计初衷是为监控系统提供实时性能数据。在典型部署中，Prometheus服务器会定期抓取这些指标（通常每分钟一次），此时累积的数据会被读取并清空。然而：

1. 在asciinema-server中，这个功能是默认开启但未在文档中说明的
2. 大多数用户并不知道这个端点的存在，因此从未查询过这些指标
3. 缺乏定期查询导致数据持续累积，形成内存泄漏

值得注意的是，同时引入的管理面板功能（监听4002端口）虽然也显示类似指标，但并非内存泄漏的直接原因，因为它采用不同的实现机制。

解决方案

项目维护者迅速响应，在v20240515版本中移除了存在问题的Prometheus指标收集端点。这一变更带来了立竿见影的效果：

1. 内存使用曲线变得平稳，不再呈现增长趋势
2. 系统稳定性显著提升，OOM Killer不再被触发
3. 基础功能完全不受影响

用户升级后的监控数据显示，内存使用量保持在健康水平，验证了修复的有效性。

经验总结

这一事件为我们提供了几个重要的技术经验：

1. 监控组件的谨慎引入：即使是看似无害的监控功能，也可能带来意想不到的副作用
2. 默认配置的安全性：生产环境中，可能消耗资源的特性应该默认关闭或提供明确配置选项
3. 全面的测试覆盖：长期运行测试对于发现内存泄漏等问题至关重要
4. 文档完整性：所有功能，特别是可能影响系统行为的特性，都应该在文档中明确说明

对于仍在使用旧版本的用户，建议尽快升级至v20240515或更高版本以获得稳定性改进。项目维护者表示未来可能会以更可控的方式重新引入监控功能，并提供明确的配置选项。