运维日志

PG 跑几个月后表体积翻了好几倍、查询越来越慢，但数据量没怎么涨——多半是 MVCC 死元组没清掉，表膨胀了。讲清死元组怎么来的、怎么量化膨胀率、autovacuum 为什么没跟上，以及手动 vacuum / 重建表 / 参数调优的具体操作，附我线上踩过的坑。

进程卡住不动、接口莫名变慢、启动就报权限拒绝——这些毛病用 top 看不出所以然。strace attach 上去追踪系统调用，能直接看到进程卡在哪个 syscall、等了多久、读写是否正常。本文讲清 attach、过滤、-e 表达式、耗时统计，以及线上不敢随便 strace 时的替代打法。

一张 5000 万行的订单表要加个索引，直接 ALTER 一跑，写入全卡、连接堆成山、从库延迟飙到几分钟——这是每个 DBA 都挨过的打。MySQL 8.0 的 ALGORITHM=INSTANT 覆盖不了所有场景，真要大表变更得靠 pt-online-schema-change 和 gh-ost 这类影子表工具。一个用触发器、一个靠 binlog，把两条路都跑通，连同坑点一起摊开。

服务半夜开始报错 accept4() failed (24: Too many open files)，或者 Nginx 频繁 502。这种故障十次有八次是文件句柄（fd）耗尽，但光改 ulimit -n 往往没用——因为 systemd 起的服务根本不吃 limits.conf 那套。从内核 file-max 到进程 LimitNOFILE，到定位到底是哪个进程在漏 fd，把每一层都讲透，并给出不停机临时救急和永久修复两条路。

pg_dump 是逻辑备份，做不了时间点恢复，库一大还慢得离谱。真要扛误删表、误更新全表这种事故，得靠物理备份加 WAL 归档的 PITR。从建备份账号、开归档、跑 pg_basebackup，到真的把库恢复到「出事前一秒」，把每一步命令和每个坑都摊开讲。

报警说磁盘 100%，可 du 加起来差了一大截；或者 df -h 明明还有空间，应用却报 No space left on device。这两种情况我都遇过不止一次，根因通常是已删除但被进程占用的文件、inode 耗尽，或者文件被挂载点盖住。逐个拆开讲怎么定位、怎么在不重启服务的前提下把空间腾出来。