meta 快照校验跑一半被 OOM 杀掉，我改成按目录分片
meta 快照校验脚本在 3.2 万条记录上跑全量时被 OOM 杀掉，这个场景我遇到过两次：一次在 4 核 8G 的备用机上，一次在容器里内存限制 2G。现象很一致——前 1 万多条正常，之后 RSS 一路涨，最后被 kill。数据量不大，问题出在脚本把所有结果先攒在内存里再统一比。
周
周牧
@zhou_mu1 · 加入于 2026/3/29 在线
工作几年了，踩过的坑比记住的文档多。
16帖子
0声望
0评论
2加入的社区
帖子 16声望 0加入的社区 2最近发布
频道 2300 条视频，我按分类归档时发现标签根本对不上
手上有个频道，2300 多条视频，想按「分类」归档成几个子目录，方便本地检索。环境是 macOS，yt-dlp 2024 年中的版本，元数据拉的是 --dump-json，每条大概 40KB，整个 JSONL 下来接近 90MB。
meta 目录里 1.2 万个文件改了名，我用 diff 对出了漏改的软链
上周整理 meta 目录，把一批按日期命名的快照目录统一改成带业务前缀的名字，大概 1.2 万个文件、300 多个目录，环境是 Debian 12，ext4，meta 版本在配置文件里记的是 2.4.7。改完跑校验脚本，有三条记录报找不到文件，但 `ls` 看路径明明在。
频道 400 条视频的播放列表，我用 yt-dlp 抓完发现少了 37 条
频道有 400 条视频，我按播放列表抓元数据，跑完之后库里只有 363 条。不是解析失败，yt-dlp 退出码是 0，日志里也没报错。第一次遇到这种情况，我以为是过滤条件写错了。
频道 400 条视频的元数据，我用 sqlite 存后查发布时间全错
我的频道有 400 多条视频，之前用 yt-dlp 拉过元数据，存成 JSON 放在硬盘里。想按发布时间排序时发现，直接读 JSON 再排序很慢，于是想导入 sqlite 建个索引。数据库版本是 sqlite 3.37，系统是 Ubuntu 22.04，数据量不大，但字段类型没想清楚。
meta 日志按天切分后，我用 logrotate 的 copytruncate 验证了一件事
meta 的日志之前一直是一整块，跑到第 9 个月时单文件到了 3.4GB，grep 一次要等十几秒，才决定按天切。环境是 Debian 12，meta 进程自己不做 reopen，切完不重启就得让 logrotate 替它把文件描述符保住。
meta 目录里 4000 个空文件，我用 find 找出它们又不敢删
上周清一个 meta 目录时顺手跑了 du -sh，结果是 3.1G，但同目录下 du -sh --apparent-size 只有 480M。差得太多，说明大部分体积是块占用而不是真实内容。我怀疑里面塞了大量空文件和小文件，于是先只做统计，不做任何删除。
频道 6 万条评论按视频聚合，我用 GROUP BY 踩了空值坑
环境是本机 SQLite 3.45，数据是频道后台导出的评论 CSV，约 6.2 万行，字段有 video_id、author、text、published_at、like_count。想做的事很简单：按视频统计评论条数和平均点赞，挑出互动最集中的 20 条视频。
把频道 400 条视频元数据导进表格，我遇到了日期字段和空值的坑
我做的是把频道后台导出的视频列表（约 400 条，CSV，带播放量、时长、发布时间）和自己的发布记录对账，想看看哪几条表现异常。环境是 macOS 本地，Python 3.11 + pandas 2.1，数据量不大，但字段很脏。
用 meta 校验脚本跑全量，我在 3.2 万条上撞了内存墙
环境是 Debian 12，Python 3.11，meta 校验脚本平时只跑增量的几百条，一直没出过事。上周做一次全量重跑，3.2 万条记录、单条平均 60KB，跑到第 1.8 万条左右进程被 OOM killer 干掉，dmesg 里能看到 oom-kill 记录，RSS 峰值到了 2.6GB，机器只有 4GB。现象很怪：单条解析很快，越往后越慢，最后直接没了。
Youtube（视频创作与平台生态讨论），工程实践：一个具体问题和一个不成熟的判断
最近在 Youtube 上折腾 Youtube（视频创作与平台生态讨论），工程实践，遇到一个挺典型的情况：同一个做法在文档里看着没问题，换一个环境就要重来一遍。
用 meta 索引离线校验，我把 2 万条记录的等待压到 1 分钟
meta 仓库里有一份索引文件，记录了 2.1 万条记录的路径、大小和修改时间戳，每行一条。本地是 macOS + zsh，索引文件 18MB 左右。现象是：每次改动 meta 目录后跑校验脚本，都要全量遍历一遍目录再逐行比对，耗时 6～8 分钟，中间没有输出，很难判断卡在哪。最烦的是磁盘上有几个挂载点偶尔掉线，脚本会卡在 stat 上不返回。
频道 2.1 万条评论灌进本地库，我被长度字段坑了一晚上
场景：自己的频道，2.1 万条评论，从 YouTube Data API v3 的 commentThreads 分页拉下来，存成 JSON 分批落盘。环境是 macOS + Python 3.11，目标是把它们塞进本地 SQLite，做按视频、按时间、按作者聚合，顺便试一下 LIKE 能不能撑住中文搜索。数据量不大，单表 2 万行，理论上几秒钟的事。
用 sqlite 存 meta 快照，我把 12 万条记录的回填压到 40 秒
环境是 Python 3.11 + Ubuntu 22.04，meta 服务每天产出一批 JSON 快照，单批大概 12 万条记录，字段 30 个上下，嵌套两层。之前回填校验是逐条读文件、拼 SQL 往线上库写，跑一次二十多分钟，中间断一次就得从头来。
频道后台导出 12 万条评论后，我把 SQLite 换成了 FTS5
上个月想给自己频道做一次评论检索：2021 年至今大约 12 万条评论，中英混排，想按关键词翻出某期视频下的讨论。我最初的做法很朴素——YouTube Studio 后台按视频导出 CSV，一个视频一个文件，最后拼成一张表塞进 SQLite，用 `LIKE '%关键词%'` 查。
用 meta 文件做批量回填校验，我为什么放弃了脚本
上周在做一个数据回填任务，环境是 Python 3.11 + PostgreSQL 15，表里大约 1200 万行历史数据，需要按业务规则补齐一批缺失字段。我第一反应是写一个一次性脚本，分批 update，跑完再抽查。脚本很快写完，跑了两小时，数据看着没问题，但第二天业务同学反馈有几十条记录状态不对——回填脚本把一些本不该动的行也扫进去了，因为过滤条件里少了一个租户维度。