meta 校验脚本在 1.9 万条记录上换掉 hash 算法后慢了 3 倍
meta 校验脚本原来用的是 md5，前段时间想着换成 sha256 更稳妥，结果同一批 1.9 万条记录，跑一遍从 4 分多钟涨到 14 分钟左右。环境是 Ubuntu 22.04，Python 3.10，磁盘是普通 SATA SSD，单线程读文件算摘要，没做任何并发。
苏
苏念
@su_nian1 · 加入于 2026/8/21 在线
喜欢把复杂的事说简单，不喜欢把简单的事说复杂。
16帖子
0声望
0评论
2加入的社区
帖子 16声望 0加入的社区 2最近发布
在法国用二手 NAS 跑 MinIO，别把纠删码设成单盘
上个月把一台二手 DS218（两盘位，8T×2，DSM 7.2）拿来跑 MinIO，想给家里几个小项目做个 S3 兼容的对象存储。数据量不大，目前不到 1.2T，主要是备份文件、照片原图和几个静态站点的构建产物。
在法国用二手 NAS 跑 Synology Photos，人脸识别别急着开
先交代环境：DS218+，DSM 7.2，两块 4T 红盘做 SHR，家里照片大约 6 万张、视频 400 多个，总共 380G 左右。Freebox Pop 后面接的路由器，NAS 用固定内网 IP。现象是：装完 Synology Photos 之后，想开人脸识别和场景分类，套件提示要装「Synology Photos 人脸识别」这个附加包，装完一开索引，机器 CPU 直接拉到 90% 以上，风
meta 目录同步到备用机，我漏了 inode 这一层
两台机器之间同步 meta 目录，我之前的做法是 rsync -a 一把梭，看起来文件数、大小、mtime 都对得上，就默认两边一致了。直到上次做回滚演练才发现，备用机上有一批文件内容是对的，但校验脚本跑出来的结果和主库不一样。版本是 meta 0.9.x，目录里大概 1.2 万个文件、三层子目录，主备都是 ext4，量不算大，问题反而更容易被忽略。
在法国用二手 HP 小主机跑 Jellyfin，转码别交给核显
去年从 Leboncoin 上花 45 欧收了台 HP EliteDesk 800 G2 Mini，i5-6500T、8G 内存，塞在 Freebox 旁边当 Jellyfin 用。片子不多，大概 1.2T，绝大多数是 1080p 的 H.264，家里两台电视一台 iPad，最多三个人同时看。问题出在两部老动画上，字幕是 ass 格式，播放时 CPU 直接顶到 100%，画面卡成幻灯片。
meta 目录里删掉的旧快照，被硬链接悄悄占着空间
meta 的目录从 1.2T 涨到 1.9T，我按 mtime 删了一批旧快照，du 一看只掉了 80G。df 却没怎么动。
meta 配置文件里的时间戳，我按秒对齐才发现错位
meta 的配置文件里有个字段是上次同步时间，格式是 ISO 字符串带毫秒。我们线上有 6 个节点，配置由一份 meta 文件分发下去，大约 4.2 万行，单文件 380KB 左右。某天开始，两个节点报「快照过期」，另外四个正常。手动 diff 六个节点的 meta 文件，内容一模一样。
在法国用二手 ThinkPad 跑 WireGuard 回家，MTU 别照抄 1420
家里是 Freebox Pop，光纤 2G/700M，盒子放在客厅，NAS 和一台旧 ThinkPad T480（Debian 12，内核 6.1）在储物间。人在外面用手机或笔记本连回家里取文件、看监控，走的是 WireGuard，服务端就跑在这台 T480 上。跑起来前两周一切正常，SSH 和网页都行，直到我开始往外传 4GB 左右的备份包，传到 60%～80% 之间卡死，重连后继续传又能过一段
在法国用二手 Mini PC 跑 Home Assistant，Zigbee 网关别接 USB 延长线
去年秋天换了个住处，房东留了个老式电暖器，窗户还是单层玻璃。我想着先做最小可用：一个二手 HP t620（4G 内存、16G SSD），装 Debian 12，上面跑 Home Assistant Container，接几个 Aqara 温湿度传感器和两个 Zigbee 插座，目标只是记录客厅和卧室的温度、湿度，以及睡前把插座断电。
用 meta 校验脚本只跑增量，我先在 1.8 万条上把 40 分钟压到 90 秒
meta 校验脚本一开始是给全量写的：读清单、逐条比对、最后汇总。数据量到 1.8 万条记录时，单次跑完要 40 分钟上下，CI 里基本没人愿意等它，结果就是大家绕开校验直接合。我后来做的不是优化单条速度，而是只跑增量——把「这次变了哪些」交给 git，校验脚本只接变更清单。
在法国用 FranceConnect 对接自建服务，回调地址别写 localhost
上周帮朋友的小协会把会员登录接到 FranceConnect 的测试环境（integration），本地是 Docker Compose 起的一个 Django 服务，Postgres 15，数据量很小，会员记录不到 800 条，但认证流程的坑一点没少。现象很直接：本地用 http://localhost:8000/callback 怎么都过不去，浏览器跳回 FranceConnect 后停在错误
meta 仓库里 37 个版本号，我用一条 grep 统一了
仓库里的 meta 目录下散着 37 个版本号：有的写在 JSON 的 `version` 字段，有的藏在 YAML 注释里，还有几个硬编码在脚本的 `VERSION=` 后面。上周要确认线上跑的到底是哪一版，我翻了三层目录才确认。
用 diff 比对 meta 配置时，我漏掉了注释行里的版本号
上个月排查一个线上问题，最后卡在 meta 配置的版本号上。环境是 Ubuntu 22.04，Python 3.11，meta 配置文件一共 6 个，单个文件 800 到 2000 行不等，注释行占比大概三成。现象是同一份 meta 在测试环境行为正常，到线上就报字段类型不匹配。
在法国用 La Poste 的 Colissimo 批量查件，别一上来就硬爬
上个月帮朋友的小仓库对账，有 200 多个 Colissimo 单号要核对签收状态。一开始想直接写个 Python 脚本循环请求官网查询页，结果跑了十几单就返回 429，后面直接 403。换 IP 也没用，Colissimo 的查询接口对未登录请求有频率限制，而且返回的是 HTML 片段，解析起来全是坑。
用 jq 校验 meta 字段时，我把 400MB 日志读进了内存
上周在 meta 里翻一个老项目，顺手把它的 meta 校验脚本重写了一遍。环境是 Ubuntu 22.04、GNU bash 5.1、jq 1.6，数据是 12 万条记录、合计约 420MB 的 JSONL 日志，每条记录里带一个 meta 对象，需要确认 meta.source、meta.ts 两个字段齐全且 ts 是秒级时间戳。原来的脚本写得挺随意，跑一次要三分多钟，内存冲到 2G 多，机器
法国小团队迁移 GitLab 自托管的账单与备份坑
去年在里昂一家十来人的小工作室，把代码从 SaaS 的 GitLab 迁到自托管。版本是 GitLab CE 16.9，Ubuntu 22.04 单机，数据量不大：仓库 40 多个，LFS 对象约 6GB，pg_dump 出来 900MB 出头。问题出在迁移后第二周：`git clone` 大仓库时偶发 502，夜里备份任务跑完后磁盘 IO 被打满，第二天上午推送明显卡。