Scrypted项目中WebRTC内存泄漏问题的分析与解决

问题背景

在Scrypted项目中使用Google Device Access插件时，发现了一个严重的WebRTC内存泄漏问题。当系统运行数天后，WebRTC插件会累积超过400个开放连接，导致LXC容器内存使用量飙升至16GB。重启WebRTC插件后，内存使用量会降至3GB左右。

问题现象

用户报告的主要症状包括：

1. WebRTC连接数持续增长，不受控制
2. 内存使用量随时间线性增加
3. 仅使用单个Nest Doorbell Wired Gen 2设备也会出现此问题
4. 问题在多种部署方式(Docker、LXC、Home Assistant、原生Node)下均能复现

技术分析

经过深入分析，这个问题与Google SDM API的工作机制和Scrypted的WebRTC实现有关：

1. Google SDM API特性：Google的SDM API设计为5分钟自动关闭流，除非被主动续订。如果续订成功，则再过5分钟后会再次关闭，除非再次续订。

2. WebRTC插件问题：Scrypted的WebRTC插件存在连接拆除时的内存泄漏问题。当WebRTC连接不再使用时，未能正确释放相关资源。

3. 预缓冲机制影响：使用WebRTC预缓冲功能会加剧这个问题，因为它会创建更多连接实例。

解决方案

项目维护者确认了这是一个WebRTC插件中的资源释放问题，并已发布修复方案。主要改进包括：

1. 实现了连接健康检查机制
2. 完善了连接终止时的资源释放流程
3. 优化了连接管理策略

临时解决方案

在官方修复发布前，用户可以采取以下临时措施：

1. 定期重启WebRTC插件
2. 使用监控插件定期清理残留RPC对象
3. 设置容器内存限制并配合earlyoom等工具
4. 调整SDM API的refreshAt参数(从4分钟改为1分钟)

最佳实践建议

1. 定期更新Scrypted到最新版本
2. 监控系统内存使用情况
3. 考虑为Scrypted容器设置适当的内存限制
4. 对于长期运行的系统，建议配置自动重启策略

这个问题展示了在复杂媒体流处理系统中资源管理的重要性，特别是在处理云设备API和WebRTC技术时。Scrypted团队的快速响应和修复体现了开源项目的优势，也为类似问题的解决提供了参考案例。