播放HTML video元素时CherryPy自动终止的故障原因问询

故障可能原因 #

1. 系统内存不足触发OOM Killer终止进程 #

日志末尾的Killed是Linux内核OOM（Out of Memory）杀手机制的典型输出，当系统可用内存不足时，内核会主动杀掉占用内存最高的进程释放资源。
你返回的视频文件单个体积接近50MB，且日志中存在大量206（分段请求）响应，部分响应返回字节数超过70MB，如果CherryPy没有配置流式响应，会将整个视频文件加载到进程内存后再返回给客户端，连续播放2-3个视频后内存占用达到阈值，就会被系统强制终止。

2. CherryPy静态资源处理配置错误 #

• 默认的CherryPy静态文件处理没有开启流式传输，处理大体积视频的分段请求时，会重复加载整个文件到内存，而非仅加载请求的分段范围，导致内存占用远超实际文件体积。
• 从curl返回的头信息看，文件实际大小为55867019字节（约53MB），但日志中存在返回超过70MB的206响应，说明服务端对range分段请求的处理逻辑存在问题，重复读取、拼接内容导致内存泄漏。

3. 资源泄漏 #

如果你的视频请求处理逻辑没有正确释放文件句柄、内存缓冲区，多次请求后系统资源被耗尽，也会触发进程被终止。

排查与修复方案 #

1. 执行dmesg | grep -i oom或者查看/var/log/syslog日志，确认是否存在OOM Killer杀掉CherryPy进程的记录，验证内存不足的判断。
2. 调整CherryPy静态资源配置，使用cherrypy.lib.static.serve_file处理视频文件时添加stream=True参数，开启流式传输，避免将整个文件加载到内存。
3. 生产环境建议在CherryPy前部署Nginx作为反向代理，所有静态视频资源直接由Nginx返回，完全规避CherryPy处理大文件的性能和内存问题。
4. 优化range请求处理逻辑，确保分段请求仅读取对应偏移量的文件内容，正确返回Content-Length头。

内容的提问来源于stack exchange，提问作者Dita Aji Pratama