文件系统选型的资源账:内存、CPU 与 IO 到底花在哪
noatime 能省掉大量元数据写入,数据库和桌面都建议开
做容量规划时,看三个数就够了:常驻内存、峰值内存、峰值持续时间。
先说结论
按「峰值 × 1.3」配内存,按「平均 × 2」配 CPU,按「峰值 × 3」留磁盘余量。
- 先量:常驻、峰值、峰值时长
- 内存:注意缓存与 RSS 的区别
- CPU:看是单核瓶颈还是多核瓶颈
- IO:随机读写最伤机械盘
- 扩容前先看是不是配置问题
三个必测的数
不测就调参,等于闭眼改代码:
- 常驻内存(RSS):决定最低配置
- 峰值内存:决定会不会 OOM
- 峰值持续时间:决定要不要限流
- 磁盘日增量:决定备份与轮转策略
内存都去哪了
Btrfs 的 df 显示原始容量,btrfs filesystem usage 才是真实可用。
| 部分 | 典型占比 | 能不能省 |
|---|---|---|
| 运行时/解释器 | 15-25% | 换实现,成本高 |
| 缓存 | 20-40% | 可以限制上限 |
| 连接/会话 | 10-30% | 设上限,及时回收 |
| 日志与缓冲 | 5-15% | 轮转 + 异步写 |
Linux 的 buff/cache 会让人误判内存不足,先看 available 而不是 free。
这个服务的几个资源事实
实测下来,它吃资源的方式比较固定:
- XFS 只能扩不能缩,分区规划错了只能备份出来重建
- noatime 能省掉大量元数据写入,数据库和桌面都建议开
- ZFS 的 ARC 会吃掉大部分空闲内存,free 只剩几百 MB 属于正常

CPU 峰值怎么处理
noatime 能省掉大量元数据写入,数据库和桌面都建议开。
峰值不可怕,可怕的是峰值期间没有排队机制,所有请求一起超时。
扩容还是优化
先做这三件事再谈扩容:限制并发、加缓存、异步化。多数「性能问题」在这三步之后就消失了。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- ext4 的 inode 数量在 mkfs 时就定死,df -i 满了但 df -h 还有空间
- 机械盘上 Btrfs 的碎片比 ext4 明显,长期写入后需要跑一次 balance
- 给 /var 选了 XFS 又想缩容,最后只能整盘备份重做
- 用 Btrfs 组 RAID5,掉一块盘后校验和报出一片错
- mkfs 时没调 inode 比例,邮件队列把小文件 inode 用光
性能优化的第一步,是知道自己现在有多慢。
评论 (3)
版本差异要强调,我照着做结果参数名全变了。
最小可用配置这个说法很好,先跑起来再优化。
排查顺序那段直接抄进值班手册了。
发表评论