一个容易踩坑的起点
验证与回滚
说到NAS EFS，很多问题都出在细节上。当你把云上的NAS或EFS挂载到服务器上，用mount -t nfs一条命令搞定后，很多人会以为它跟本地硬盘一样——写文件，读文件，完事。直到并发量上来，发现写入延迟从2ms飙升到200ms，甚至服务卡死，才意识到“远程文件系统”跟本地磁盘完全是两码事。
NAS（Network Attached Storage）或EFS（Elastic File System）本质上是通过网络（通常是NFS协议）暴露的一个分布式存储池。每一次 open()、write()、close() 都会发起网络请求，涉及客户端与存储集群之间的多次握手。在高并发读写场景下（比如容器集群写日志、AI训练读取样本、视频转码中间件），这些网络开销会被放大，造成性能瓶颈。调优的核心，就是减少不必要的网络交互、最大化传输效率。
先理解NFS在背后做了什么——NAS EFS
NFS（Network File System）是一个“无状态”协议，客户端发一个RPC请求，服务端回复结果。默认挂载参数（比如Linux自带的 mount -t nfs4）通常针对单用户、低并发场景设计，追求易用和兼容性，而不是高性能。你需要主动调整几个关键参数，才能适应高并发。
以下参数是调优的起点，理解它们比直接抄命令更重要。
rsize 和 wsize：单次传输的“一口吃多少”
rsize 和 wsize 分别控制每次读、写请求能携带的最大数据量（字节）。默认值通常是 1MB（1048576），但很多云厂商推荐的内部块大小不是这个值。为什么？因为NFS在底层会把一个大的写请求拆成多个RPC调用。如果 wsize 太大，网络丢包重传代价高；如果太小，同样数据量需要更多网络交互，CPU开销飙升。
高并发调优原则：针对吞吐类场景（顺读顺写大文件），适当增大到 1MB；针对延迟敏感的小文件场景，降低到 256KB 甚至 128KB。但不要超过云厂商建议的最大值（例如AWS EFS建议wsize≤1MB，阿里云NAS建议≤1MB）。
可以这样测试：用 fio 分别跑 --bs=256k 和 --bs=1m 对比IOPS和延迟，选择最优值。
hard vs soft：掉线时你是等还是忍
hard 挂载：当NFS服务端无响应时，客户端会一直重试，直到恢复。应用层的文件读写操作会被阻塞，看起来像进程挂起。这也是很多人用NFS时“服务器卡死”的常见原因。soft 挂载：超时后直接返回错误给应用层，应用可以自己处理失败（比如重试或跳过）。
高并发场景下，推荐使用 hard,intr 或 hard（配合适当超时），因为如果服务端偶尔抖动但很快恢复，hard 能保证数据不丢失，而 soft 会导致应用层频繁遇到EIO错误。但必须调整timeo（超时时间）和 retrans（重试次数），避免重试太久。
noatime 和 nodiratime：关掉“访问时间戳”
每次读取文件，默认都会写一个 atime 元数据更新，这需要一次额外的网络写入。高并发下这个开销非常可观。加上 noatime 让内核不更新atime，nodiratime 同理。绝大多数应用根本不需要atime，这是一个零代价的性能提升。
actimeo：缓存元数据多久不过期
actimeo 控制属性缓存（attribute cache）的有效期。默认很短（秒级），意味着每次 ls -l 或 stat() 都可能触发网络请求。将 actimeo 增大到 30-60 秒，可以大幅减少元数据请求。对于写多读少的日志场景，甚至可以让它更长。但注意：如果你在多节点间共享同一文件并频繁修改权限，不要设太大，否则可能看到陈旧的属主信息。
进阶阅读：此处可内链到“NAS EFS性能优化”指南。
网络层面的调优
NAS/EFS依赖底层TCP连接。高并发时，默认的TCP参数会限制吞吐。
增大TCP缓冲区
读写rsize/wsize时，数据会经过TCP socket缓冲区。如果缓冲区太小，单次传输会被切分，增加CPU开销。推荐调大：
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216并发NFS连接数
一些云文件系统（如阿里云NAS）支持在挂载时指定多个TCP连接（即nconnect参数）。默认单连接，在并发请求多时会排队。如果客户端和NAS之间没有连接数限制，加上 nconnect=4 或 8 可以让多个请求并行传输。
注意：不是所有客户端内核都支持nconnect，需要Linux内核4.8+，且NFS版本配合。检查 /proc/fs/nfsfs/volumes 确认连接数。
MTU与巨帧
如果NAS与客户端在同一个VPC内，将MTU设为9000（巨帧），可以减少头部开销。但务必确保链路上所有网络设备支持，否则出现碎片反而降低性能。
补充参考：此处可内链到“NAS EFS故障排查实例”。
客户端内核参数：NFS挂载点专属
除了系统级TCP调优，NFS自身还有几个内核参数可以借力。
收尾页与预读
对于顺序读取场景，NFS客户端的预读（read-ahead）可以隐藏延迟。但很多云环境默认预读较小。调整一个挂载点的预读大小：
blockdev --setra 4096 /dev/sda （实际是设置块设备预读，但NFS挂载点通常没有对应块设备，需要通过mount选项max_readahead_kb 或 sysfs 调整）更好的方法是在挂载时使用 mount -o rsize=1048576,wsize=1048576,hard,noatime,actimeo=30,nconnect=4 完整参数。
强制使用异步IO
应用层如果使用同步IO（如 O_SYNC），每个写操作都会等待数据持久化到磁盘，高并发下性能极差。确保你的应用使用异步IO，或者将挂载点设为 sync=async（默认就是async）。
关联教程：此处可内链到“NAS EFS部署与验证”内容。
验证与回滚——NAS EFS
实际操作要点
调优后务必用工具验证，而不是凭感觉。
- fio测试：
fio --name=test --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=16 --direct=1 --runtime=30 --group_reporting - 观察延迟：挂载点下执行
iostat -x 1看await和svctm；用nfsstat -c看客户端RPC统计。 - 监控云产品侧：大多数云厂商控制台提供IOPS、吞吐、延迟指标，与客户端数据对照。
如果调优后性能反而下降，回滚很简单：重新挂载去掉多余参数，或修改 /etc/fstab 重启服务。注意nconnect 不支持热调整，需卸载重挂。
一个常见案例：Docker容器写日志到EFS
故障定位思路
某团队用Kubernetes运行微服务，所有日志写入AWS EFS。默认挂载参数下，日志写入延迟不断上升，进而导致容器OOM。调优步骤：
- 改为
hard,noatime,nodiratime,actimeo=60,wsize=512k,rsize=512k - 在节点上设置
nconnect=8 - 去掉应用中的
O_SYNC标志 - 结果：写入IOPS稳定，延迟从50ms降到5ms
注意，这个案例不编造细节，只是说明方向。
最后说两句
我的处理经验
NAS/EFS不是银弹，它适合读多写少或写后立即读的场景，但高并发随机写入时需要考虑换用分布式数据库或消息队列。调优只是让它在能力边界内跑得更稳。
下一次挂载前，请记住这五个字：参数即性能。按这个顺序复查，NAS EFS遇到异常时也更容易定位。
延伸阅读