边缘设备连续掉线 8 小时的完整复盘从重启就好到根因修复越微智能Yuewell工业边缘 AI 工程实践系列 · 第 6 篇关键词事故复盘、掉线、systemd 重启风暴、维护锁、网络恢复、RTSP 重连、看门狗一、事故概述一个重启就好的问题持续了 8 小时2026 年 6 月我们的一个垃圾转运站项目现场一台 RK3588 边缘 AI 设备出现了连续掉线的问题。现象设备每隔 30-60 分钟掉线一次平台显示设备离线每次掉线后大约 2-5 分钟自动恢复现场人员 SSH 上去看进程都在端口都在监听但平台就是连不上现场人员的第一反应是重启就好但重启后过一段时间又掉线这个问题从早上 8 点持续到下午 4 点整整 8 小时期间设备累计离线时间超过 2 小时客户的投诉“你们这个设备怎么回事一天掉好几次线我们的巡检数据都断了。每次都是重启就好但过一会儿又掉。你们能不能彻底解决一下”这是一个典型的间歇性故障——不是完全不工作而是时好时坏每次都能重启就好但根因没有找到问题持续存在。本文完整复盘这次事故的排查过程、根因分析、修复方案以及我们从中沉淀的工程规范。二、第一阶段排查“进程都在为什么平台连不上”2.1 初步排查现场人员 SSH 上去后做了以下检查# 1. 检查进程psaux|grepyw_# 结果yw_core 和 yw_algo_server 都在运行# 2. 检查端口ss-tlnp|grep5005# 结果50051 和 50052 都在监听# 3. 检查 UDS 套接字ls-l/tmp/yw_algo_fd.sock# 结果文件存在# 4. 检查日志tail-50logs/yw_core_20260608.log# 结果没有明显的错误日志所有检查都显示一切正常但平台就是连不上。这时候现场人员的判断是“可能是网络问题重启一下就好。”重启后确实恢复了但过了 40 分钟又掉线了。2.2 关键发现掉线时的日志第二次掉线时现场人员没有立即重启而是先抓了完整的日志。这是整个排查过程中最关键的一步。# 掉线时查看最近 500 行日志grep-EERROR|WARN|FATAL|disconnect|offline|reconnectlogs/yw_core_*.log|tail-100关键日志片段[2026-06-08 10:23:15] [INFO] [PlatformClient] 平台心跳超时开始重连... [2026-06-08 10:23:16] [INFO] [PlatformClient] 重连平台 ws://platform.xxx.com:8080/ws [2026-06-08 10:23:17] [ERROR] [PlatformClient] 重连失败Connection refused [2026-06-08 10:23:20] [INFO] [PlatformClient] 重连平台 ws://platform.xxx.com:8080/ws [2026-06-08 10:23:21] [ERROR] [PlatformClient] 重连失败Connection refused ...重复 10 次 [2026-06-08 10:24:30] [INFO] [PlatformClient] 重连成功设备上线关键发现不是设备掉线而是设备到平台的 WebSocket 连接断了重连失败了大约 1 分钟然后自动恢复了。平台显示设备离线是因为 WebSocket 断连而不是设备本身不工作。2.3 为什么重连会失败 1 分钟进一步排查发现重连失败的原因是DNS 解析失败# 掉线时测试 DNSnslookupplatform.xxx.com# 结果;; connection timed out; no servers could be reached现场的网络环境是设备通过 4G 路由器上网DNS 服务器配置的是运营商的 DNS。4G 网络不稳定时DNS 解析会超时。但这还不是完整的根因——因为 DNS 恢复后重连应该立即成功不应该持续 1 分钟。三、第二阶段排查systemd 重启风暴3.1 发现重启风暴继续查看 systemd 日志journalctl-uyw-avis-backend.target--since2026-06-08 10:00--until2026-06-08 11:00关键发现10:23:15 yw_core[12345]: 平台心跳超时开始重连... 10:23:17 yw_core[12345]: 重连失败Connection refused 10:23:18 systemd[1]: yw-core.service: Main process exited, codekilled, status9/KILL 10:23:18 systemd[1]: yw-core.service: Failed with result signal. 10:23:28 systemd[1]: yw-core.service: Scheduled restart job, restart counter is at 3. 10:23:28 systemd[1]: Stopped Yuewell AI Vision Core Service. 10:23:28 systemd[1]: Started Yuewell AI Vision Core Service. 10:23:29 yw_core[12400]: 启动中... 10:23:30 yw_core[12400]: Preflight Check: PASS 10:23:31 yw_core[12400]: 连接推理引擎... 10:23:31 yw_core[12400]: UDS 套接字就绪 10:23:32 yw_core[12400]: 加载任务配置... 10:23:33 yw_core[12400]: 启动 RTSP 拉流... 10:23:35 yw_core[12400]: 连接平台... 10:23:36 yw_core[12400]: 平台连接成功 10:23:36 yw_core[12400]: 设备上线关键发现yw_core 进程被 SIGKILL信号 9杀掉了不是正常退出是被强杀的。3.2 谁杀了进程继续排查# 查看 OOM Killer 日志dmesg|grep-ioom\|killed|tail-20结果[10:23:18] Out of memory: Killed process 12345 (yw_core) total-vm:524288kB, anon-rss:385024kB, file-rss:0kB, shmem-rss:0kB [10:23:18] oom_reaper: reaped process 12345 (yw_core), now anon-rss:0kB根因找到了OOM Killer 杀掉了 yw_core 进程设备的物理内存是 4GByw_core 进程占用了 385MBanon-rss看起来不算多。但为什么会 OOM3.3 内存泄漏的真相继续查看内存使用历史# 查看 yw_core 进程的内存使用趋势grepmemory_usage\|rsslogs/yw_ops.log|tail-50发现08:00:00 yw_core RSS: 185MB 09:00:00 yw_core RSS: 245MB 10:00:00 yw_core RSS: 310MB 10:23:18 yw_core RSS: 385MB → OOM Killedyw_core 进程的内存使用在持续增长每小时增长约 60MB。这是典型的内存泄漏。3.4 内存泄漏在哪里进一步分析代码发现内存泄漏在RTSP 拉流重连逻辑中当 RTSP 连接断开时代码会重新创建一个拉流会话但旧的会话没有正确释放——FFmpeg 的AVFormatContext、AVCodecContext、帧缓冲区都没有释放每次重连泄漏约 5-10MB现场 4G 网络不稳定RTSP 频繁断连重连内存泄漏加速这就是完整的事故链4G 网络不稳定 │ ├── RTSP 频繁断连重连 → 每次重连泄漏 5-10MB → 内存持续增长 │ │ │ └── 2 小时后内存耗尽 → OOM Killer 杀掉 yw_core │ └── WebSocket 平台连接断连 → DNS 解析超时 → 重连失败 1 分钟 │ └── 平台显示设备离线两个问题叠加导致了设备频繁掉线的现象。四、第三阶段排查为什么重启后 40 分钟又掉线找到 OOM 根因后还有一个问题没解释为什么重启后 40 分钟又掉线重启后内存应该是干净的不应该 40 分钟就 OOM。继续排查发现了第二个问题systemd 重启风暴 维护锁误触发。4.1 重启风暴OOM 杀掉 yw_core 后systemd 的Restarton-failure会在 10 秒后自动重启。但重启后RTSP 拉流重新建立如果网络还是不稳定RTSP 继续频繁断连内存泄漏继续这次因为初始内存已经有一些基础占用加上泄漏速度更快网络更差时重连更频繁40 分钟就再次 OOM这就形成了重启风暴OOM → 重启 → 40 分钟后再次 OOM → 再次重启……4.2 维护锁误触发还有一个更隐蔽的问题维护锁误触发。我们的维护锁机制是systemctl stop时创建维护锁systemctl start时删除维护锁。但 OOM Killer 杀掉进程时不经过ExecStopPost所以不会创建维护锁——这是正确的设计。但问题出在现场人员手动systemctl stop做排查时创建了维护锁然后排查完忘记systemctl start而是直接reboot了设备。设备重启后维护锁文件还在因为锁文件存在磁盘上重启不丢失。systemd 启动服务时ExecStartPre检测到维护锁存在拒绝启动。结果设备重启后yw_core 服务没有启动平台显示设备离线。现场人员以为是又掉线了再次重启还是一样。直到我们远程排查发现维护锁的存在手动删除后才恢复。这是一个典型的运维操作不规范导致的二次故障。五、根因总结与修复方案5.1 三个根因#根因影响严重程度1RTSP 重连时 FFmpeg 资源未释放内存泄漏每小时泄漏 60MB2 小时 OOM 高24G 网络不稳定导致 RTSP 频繁断连加速内存泄漏泄漏速度从 60MB/h 提升到 100MB/h 中3维护锁在 reboot 后残留导致服务拒绝启动设备重启后服务不启动平台离线 中5.2 修复方案修复 1RTSP 重连资源释放根因 1重连时先调用avformat_close_input释放旧的AVFormatContext调用avcodec_free_context释放旧的AVCodecContext调用av_frame_free释放所有未处理的帧缓冲区增加资源泄漏检测每次重连后打印当前内存使用异常时告警增加重连频率限制1 分钟内重连超过 5 次时退避到 30 秒重连一次避免频繁重连加速泄漏修复 2网络不稳定时的退避策略根因 2RTSP 断连后采用指数退避重连1s → 2s → 4s → 8s → 最大 30s网络恢复后逐步恢复到正常重连间隔增加网络质量监控持续检测 ping 延迟和丢包率网络质量差时降低分析帧率从 10fps 降到 5fps减少 RTSP 带宽需求修复 3维护锁启动时自动清理根因 3ExecStartPre检测到维护锁时不再直接拒绝启动而是检查锁文件的时间戳如果锁文件存在超过 10 分钟说明是异常残留不是正在维护自动删除并继续启动如果锁文件存在不足 10 分钟可能是正在维护拒绝启动并输出明确提示增加maintenance.lock的 TTL 机制锁文件创建时写入过期时间过期后自动失效5.3 额外加固内存压力软降级除了修复根因我们还增加了内存压力软降级机制进程内监控自身 RSS 内存使用内存达到 warn 阈值70%时降低预览帧率、释放 JPEG 缓存、暂停非关键任务内存达到 critical 阈值85%时主动关闭部分 RTSP 拉流会话释放内存内存恢复后逐步恢复正常运行这个机制不能替代内存泄漏修复但可以作为最后一道防线在内存泄漏被发现和修复之前避免 OOM Killer 强杀进程导致的服务中断。六、事故时间线完整复盘时间事件06-08 08:00设备正常运行yw_core RSS 185MB06-08 09:004G 网络开始不稳定RTSP 频繁断连yw_core RSS 245MB06-08 10:00yw_core RSS 310MB平台 WebSocket 开始间歇性断连06-08 10:23yw_core RSS 385MBOOM Killer 杀掉进程平台显示离线06-08 10:24systemd 自动重启 yw_core设备恢复上线06-08 11:00现场人员手动 stop 排查创建维护锁然后 reboot 设备06-08 11:02设备重启后维护锁残留yw_core 拒绝启动平台离线06-08 11:30现场人员再次重启问题依旧电话求助06-08 12:00我们远程登录发现维护锁残留手动删除服务启动06-08 12:10设备恢复上线但内存泄漏根因未修复06-08 13:00yw_core RSS 再次增长到 280MB06-08 14:00我们远程部署修复版本RTSP 资源释放 退避策略06-08 14:30修复版本上线内存使用稳定在 200MB 左右06-08 16:00连续运行 1.5 小时无内存增长事故确认解决七、越微自研Yuewell-Incident 故障诊断与恢复规范这次事故后我们沉淀了Yuewell-Incident 故障诊断与恢复规范核心包括三级故障分类P0完全不可用/ P1部分功能异常/ P2性能下降不同级别有不同的响应时间和处理流程故障排查五步① 抓日志不重启 → ② 查进程/端口/资源 → ③ 查 systemd/OOM/dmesg → ④ 查网络/DNS/连接 → ⑤ 查代码/配置变更内存泄漏检测进程内 RSS 监控 定时日志 异常告警内存持续增长时自动触发诊断RTSP 重连退避指数退避 重连频率限制 资源释放校验杜绝重连泄漏维护锁 TTL 机制锁文件带过期时间启动时自动清理过期锁杜绝残留锁导致服务不启动内存压力软降级warn/critical 两级阈值自动降帧/释放缓存/关流避免 OOM 强杀事故复盘模板时间线 / 根因 / 影响 / 修复 / 加固 / 预防每次事故必须输出复盘文档这套规范让我们的现场设备从出问题靠重启变成了出问题有诊断、有恢复、有复盘、有预防。在后续的项目中类似的内存泄漏问题在上线前就被检测到没有再造成现场事故。八、写在最后边缘设备的故障排查最忌讳的就是重启就好。重启确实能解决很多问题但它也会抹掉故障现场让根因永远找不到。问题不会因为重启而消失它只会在下次更严重的时候爆发。越微智能在 RK3588 边缘 AI 视觉设备的量产交付中经历了从出问题就重启到出问题先抓日志再排查的完整演进把这些踩过的坑沉淀成了 Yuewell-Incident 故障诊断与恢复规范。我们相信故障诊断和恢复能力是边缘 AI 产品从能交付到能运维的核心服务能力。如果你也在做边缘设备的生产化运维欢迎交流。关于作者越微智能Yuewell专注具身智能与工业 AI 视觉落地基于自研 VLA 多模态大模型提供全品牌机器人二次开发适配宇树/优必选/智元/傅利叶与工业级视觉算法定制支持从算法、硬件到产线实机部署的全栈交付。