备案站点的磁盘 IO 与文件系统运维

磁盘一慢，整台机器都在等

这类故障的典型现场是：CPU 使用率只有百分之十几，负载却高得离谱，所有接口一起变慢。因为进程不是在计算，而是在排队等磁盘。只盯 CPU 使用率的监控看板，对这种情况完全没有反应。

关键要点

• 「CPU 空闲但系统很慢」几乎都是 IO 等待，要看 IO 延迟与设备队列深度，而不是 CPU 使用率。
• 磁盘写满有两种：空间满和 inode 满，后者更迷惑——显示还有几十 G 可用，却创建不了任何新文件。
• 删了文件空间不回收，通常是进程还持有已删除文件的句柄。
• 云盘有突发额度，耗尽后掉回基线性能，表现为「跑着跑着突然变慢」。

IO 问题的判读

现象	关键指标	结论
CPU 低、负载高、请求普遍慢	IO 等待占比高，设备利用率接近饱和	磁盘已成瓶颈
平时正常、偶发长尾延迟	IO 延迟 P99 尖峰、队列深度突增	有大块写入抢占：备份、日志轮转、合并任务
运行一段时间后突然变慢	吞吐掉到某个固定值	云盘突发额度耗尽，回落到基线配额
空间没满却写入失败	inode 使用率满	小文件过多

云盘的 IOPS 与吞吐通常按规格和容量分配，还带一份可积累的突发额度。积分用完前后的性能可以差好几倍，这类「无故障但明显变慢」的现象，查监控往往一眼就能看出拐点。规格与费用的权衡见 服务器资源与成本治理。

空间、inode 与句柄：三类「写不进去」

• 空间满：最常见，也最直接。连锁反应很凶——数据库可能进入只读或直接崩溃、日志写不进去、新进程起不来、健康检查随之失败并触发实例被摘除，见 优雅停机与健康检查。
• inode 满：文件数量耗尽索引节点。典型来源是海量小文件：会话文件、缓存碎片、临时上传目录、按秒切割的日志。表现是空间看着还很宽裕却创建不了文件，非常容易误判。
• 句柄未释放：日志文件被直接删除，但写进程仍持有它的句柄，空间不会回收——磁盘继续满，而你已经找不到那个文件了。正确做法是走日志轮转的重开流程，而不是直接删文件。

排查顺序建议固定成三步：先看空间，再看 inode，最后看是否有进程持有已删除文件。三步都过一遍，通常十分钟内能定位。

数据与日志分盘，备份要限速

同一块盘上既跑数据库又写日志，是延迟抖动的经典来源：日志一轮转、备份一开始，数据库的 IO 延迟就跟着抖。三条基本纪律：

• 日志独立分区，并配好轮转（按大小切割、限制份数、压缩历史），字段与采集规范见 日志规范与集中检索，留存期限要求见 网站访问日志留存要求。
• 备份任务限速并错峰，别和业务高峰或数据库合并任务撞在一起，见 数据备份与容灾。
• 大批量数据清理分批限速，一次删几百万行会把 IO 打满，见 数据生命周期与归档清理。

写入路径：返回成功到底意味着什么

应用写入到数据真正落盘之间隔着多层缓存：应用缓冲、操作系统页缓存、设备缓存。数据库的刷盘策略决定了「提交成功」的含金量——刷盘越严格越安全、越慢；放宽刷盘能显著提升吞吐，代价是掉电或宕机时可能丢掉最后一小段事务。

这是一个必须由业务显式决策的取舍，不该由默认值决定。需要注意的是：云盘通常自带多副本，能防磁盘损坏，但防不住「进程写了但还没落盘就宕机」，应用层的刷盘语义不能因为用了云盘就省掉。数据库侧的高可用配合见 数据库运维与高可用。

写放大与容量水位

随机小块写入到底层实际写入的数据量会被放大：文件系统的元数据、数据库的预写日志、SSD 的擦除块与垃圾回收都会贡献放大系数。两个实用结论：

• 批量顺序写远比零散随机写划算，这也是很多存储引擎把随机写转成顺序写的原因。
• 别让盘长期接近写满：可用空间不足时垃圾回收效率下降，写延迟会明显上升，通常建议长期水位控制在 80% 以下。

容器与网络存储的两个坑

容器把日志写进容器可写层而不是挂载卷，是节点磁盘被写满的高频原因——一个服务刷日志，整台节点上的容器一起遭殃。日志应输出到标准输出或挂载卷并配轮转，见 容器化部署要点。

另一个坑是把数据库数据目录放在网络文件系统上：延迟特性和文件锁语义与本地盘差别很大，容易出现难以定位的卡顿与一致性问题。

监控：要的是「还有多久写满」

只设「使用率超过 90% 告警」是不够的——从 90% 到写满可能只要两小时。有效的磁盘监控是四项：

指标	意义
空间使用率	基础水位
inode 使用率	漏了它就会被小文件打穿
增长速率推算的剩余时间	按当前速度还有多少天写满，最有行动价值
IO 延迟 P99 与队列深度	性能侧的早期信号

告警接入见 备案网站监控告警体系，指标采集与关联分析见 可观测性建设，容量趋势的长期规划见 容量规划与弹性伸缩。

常见坑

• 只监控空间不监控 inode：空间充足却创建不了文件，排查方向全错。
• 直接 rm 日志文件：空间不回收，问题依旧还多了个坑。
• 数据与日志同盘：备份和轮转期间数据库延迟抖动。
• 忽视云盘突发额度：把配额问题当成应用性能退化排查。
• 磁盘长期跑在 90% 以上：写延迟上升，且没有任何缓冲时间应对突发。

常见问题

IO 等待高就一定是磁盘坏了或不够快吗？

不一定。也可能是某个进程在做大量随机读写（如无限制的批量任务），或内存不足导致频繁换页、把内存压力转化成了磁盘压力。先定位是哪个进程、哪种访问模式，再判断是换盘还是改程序。内存侧的排查见 内存泄漏与 OOM 排查。

显示还有很多可用空间，为什么创建文件失败？

大概率是 inode 耗尽。检查 inode 使用率，并找出小文件集中的目录——通常是临时文件、会话文件或切割过细的日志。清理之后要顺手把产生小文件的源头治理掉。

删掉大日志后空间为什么没回来？

写进程仍持有该文件的句柄，空间要等进程关闭句柄才释放。用轮转工具的重开机制处理，或让进程重新打开日志文件；紧急情况下重启该进程也能释放。

磁盘使用率到多少该扩容？

比阈值更有用的是增长速率：按当前速度推算剩余天数，少于预留处理周期（例如两周）就该动手。长期水位建议控制在 80% 以下，给突发增长和垃圾回收留出余量。

资料来源

Linux 文件系统与块设备层的公开文档、主流云厂商关于云盘性能配额与突发额度的说明，以及主流数据库刷盘与预写日志相关的官方文档。本文为通用运维说明，仅供参考，具体以实际存储类型与数据库配置为准。