Linux 文件系统性能优化思路

ext4调优需分层处理：挂载参数（noatime、data=writeback、barrier=0）、inode密度（mke2fs -i）、IO调度器（NVMe用none）、vm.swappiness调低，并优先排查iostat/iotop确认真因。

ext4 文件系统挂载参数调优

默认挂载的 ext4 往往没开性能关键选项，尤其在高并发小文件或日志写入场景下容易成为瓶颈。常见误区是只调 noatime，其实更关键的是 data=writeback 和 barrier=0（后者仅限有掉电保护的 RaiD/SSD）。

实操建议：

• noatime 必加，避免每次读都触发磁盘写；relatime 是折中，但现代内核下 noatime 更稳妥
• 数据库或日志服务可试 data=writeback，跳过日志同步开销；但注意崩溃后可能丢失未提交事务
• barrier=0 仅当确认存储层有电容/闪存断电保护时启用，否则 barrier=1（默认）必须保留
• SSD 上建议加 discard（若支持 TRIM）或定期跑 fstrim，避免长期使用后写放大

inode 与 block 分配策略调整

新建大容量文件系统时，mke2fs 的初始参数直接影响后续扩展性。默认 inode 数量按每 16KB 一个分配，小文件多的场景（如容器镜像仓库、git 仓库）很快耗尽 inode，报错 No space left on device 却 df -h 显示空间充足。

实操建议：

• 创建时用 mke2fs -i 8192（每 8KB 一个 inode）提升小文件密度；极端情况可到 -i 4096，但会略微增加元数据开销
• 已有文件系统无法直接增 inode，只能 dump/restore 重建，务必提前规划
• 用 tune2fs -l /dev/sdXN | grep "Inode count" 查当前总量，df -i 看剩余，别等报错才查
• 对顺序大文件场景（如视频归档），反而可加大 -i 值（如 32768），节省 inode 表空间

IO 调度器与队列深度匹配硬件

linux 内核的 IO 调度器（cfq、deadline、noop、kyber、mq-deadline）不是越新越好，得看后端设备类型。NVMe SSD 上用 cfq 反而引入无谓延迟，而传统 HDD 上关调度器（noop）又可能降低吞吐。

实操建议：

• NVMe 设备强制设为 none（即绕过调度器）：echo none > /sys/block/nvme0n1/queue/scheduler
• SATA SSD 推荐 mq-deadline 或 kyber（5.0+ 内核）；HDD 仍用 mq-deadline 较稳
• 检查当前值：cat /sys/block/sda/queue/scheduler，中括号标出的是生效项
• 队列深度也需对齐：NVMe 默认 nr_requests=128 够用，但高并发场景可调至 256；SATA SSD 建议保持 32~64

避免 swap 对文件系统 IO 的隐式干扰

当内存紧张时，内核可能把脏页回写延迟到 swap 分区，导致 pdflush 或 writeback 进程突然扫盘，拖慢正常文件 IO。这不是文件系统本身问题，但现象常被误判为磁盘慢。

实操建议：

• 调低 vm.swappiness 至 1（非零以防 OOM killer 过早触发），禁止主动换出匿名页
• 确认 swap 是否真被使用：grep -i "swap" /proc/meminfo，若 SwapTotal 非零但 SwapFree ≈ SwapTotal，说明基本没走 swap
• SSD 上禁用 swap 更彻底：卸载后 swapoff /dev/sdXN，再从 /etc/fstab 删除对应行
• 监控 pgpgin/pgpgout（/proc/vmstat）突增，可佐证 swap 引发的 IO 波动

真正卡顿往往不在文件系统层本身，而在调度器、内存回收、块设备队列这些“夹层”。调参前先用 iostat -x 1 看 %util 和 await 是否真高，再查 iotop 定位进程，最后才动挂载参数或 tune2fs —— 否则容易把负载均衡问题当成磁盘问题修。