计算机视觉网站扩容难？三步清除存储冗余

　　去年六月，凌晨三点十七分，我盯着后台的磁盘IO曲线像盯着心电图——它平了，但不是健康那种平，是死透了那种平。服务器在撑，可上传队列已经堆到第八次重试失败，新来的CV标注任务全卡在“等待存储分配”状态。我手边泡的枸杞茶凉透了，杯底浮着三颗没泡开的干果。

　　运维小王在 Slack 里敲：“张工，又报502，这次是 /api/v2/submit-batch，前端说连重试按钮都灰了。”我回了个“嗯”，其实那会儿我已经知道不是API的事——日志里没错误码，只有三万两千条“StoragePool::reserve failed: capacity exhausted”，每条后面跟着同一个UUID，重复了整整二十三分钟。我原以为是模型缓存爆了，结果一查，那些UUID全指向同一个用户上传的、被标记为“待审核”的视频帧切片集合，一共一千四百三十二个，单个平均38MB，全部落盘但没进数据库索引。

　　办公室空调冷气太足，我后颈一直发麻。刘总监踩着拖鞋冲进来时衬衫扣子系错了两粒，他拿手机照着屏幕念：“你们清一下冗余数据……这词儿谁写的？冗余？我昨天还看见首页推了‘实时视觉增强’，怎么连上传都卡？”他话没说完，监控系统弹出新告警：ceph集群OSD 17 宕机，原因写着“disk full”，可磁盘使用率只显示72%。我盯了五秒，拔掉U盘（里面存着上周的防火墙规则备份，一直没格式化），插回电脑，又拔出来——就这个动作，桌面右下角时间跳了一秒，变成三点二十一分。

文章配图，仅供参考

　　我们动手删的不是重复图片，是那些标了“skip-review”却仍占用块设备空间的中间态文件：前两天训练用的负样本集、自动裁剪后残留的原始视频帧、还有AI预处理模块写入的临时tensor blob——它们有命名规则，带ts_和_v4x后缀，但不进任何清理定时任务，因为没人给它们加TTL字段。我写了三行脚本，第一行grep出所有含“ts_20230607”且路径含“/tmp/preview/”的文件；第二行用stat -c "%y %n" 批量输出修改时间；第三行直接rm -f，没加任何确认。执行完，磁盘使用率掉到58%，502停了，上传队列开始蠕动。可就在那一刻，我手机震了一下，是客服部转来的用户投诉截图，只有一行字：“我昨天传的32段工厂巡检视频，今天点进去全变黑屏，提示‘资源不可用’。”

　　我没回。因为我知道，那些视频确实没了——不是删错了，是根本没真正存过。系统只存了首帧缩略图和元数据，真文件在转码中途就被OOM Killer干掉了，但状态机卡在“processing”，而存储回收脚本只认“completed”或“failed”。所以“优胜劣汰”这四个字站得住，不是因为它多优雅，是它真能活下来：活下来的文件有完整链路，有MD5校验，有下游调用记录；淘汰的，连error_log都不配进ES。小王递来半块巧克力，铝箔纸没撕干净，黏在他拇指上。他问：“张工，那个用户……要人工恢复吗？”我说不知道。反正他们也没留原始链接，再说，恢复哪一段？第几帧？还是第几个自动切分出来的0.8秒片段？

　　现在快五点了，窗外天灰得发青。我刚发现终端里有个进程还在跑：ps aux | grep clean_tmp，PID 2891，USER root，CPU 0.0%，但RSS占了三百二十兆——查了下，它是三年前某次热修复打的补丁，没人记得它干嘛用，也没人敢kill。刚才删冗余的时候，它自己启动了，八成是检测到inotify事件。有谁碰到过这个吗？

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!