Efs

efs

3. 检查是否用了 Infrequent Access（IA）存储类
   如果你启用了生命周期策略，小文件会被移到 IA 存储类，首次访问延迟高达几十毫秒，会加剧 IO wait 
   。
   建议关闭 IA 或强制把热点文件留在 Standard 存储类

https://www.amazonaws.cn/efs/faq/

说明瓶颈在 **EFS I/O 延迟** 或 **EC2 与 EFS 之间的网络/挂载参数** 上。

---

## 🧩 一、问题本质分析

> EC2 load 高 + `wa`（I/O wait）高
> ⇒ 表示 CPU 大部分时间在等待 I/O 完成，而不是 CPU 算力不足。

**典型原因：**

1. **EFS 性能模式或吞吐量限制（Throughput/IOPS）**

   * 默认的 **General Purpose 模式** 适合低延迟小文件，但 I/O 并发量一高就会严重卡。
   * 如果你的应用做了大量小文件读写（如日志、批量数据处理），I/O wait 会爆表。

2. **挂载方式/参数不当**

   * 未开启 NFS 客户端缓存（例如未挂载 `nfs4.1` + `noresvport` 等）。
   * 未启用 `EFS Mount Helper` 的 `tls` 优化。

3. **网络延迟或带宽瓶颈**

   * EFS 是网络文件系统（依赖 VPC 网络性能）。
   * 如果 EC2 在另一个 AZ 或未开启 “Mount target in same AZ”，性能会极差。

4. **系统问题叠加：**

   * swap 触发或内核 page cache 压力大。
   * 多线程访问同一个文件导致锁等待。

---

## 🧰 二、排查思路

可以先确认是不是 EFS 导致的：

```bash
# 1. 查看 load 和 I/O wait
top
# 重点看 %wa

# 2. 确认 CPU 实际使用情况
mpstat 1

# 3. 查看哪个进程卡在 I/O
iotop -oPa

# 4. 测试网络延迟
ping <EFS mount target IP>

# 5. 检查挂载参数
mount | grep efs
```

示例问题输出（常见）：

```
/mnt/efs on fs-xxxx.efs.ap-east-1.amazonaws.com:/ type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576)
```

→ 如果没看到 `noresvport`、`nconnect=4`、`tls`，说明挂载参数还没优化。

---

## ⚙️ 三、解决/优化方案

### ✅ 1. 优化 EFS 性能模式

进入 AWS 控制台 → EFS → File system → “Performance”：

* **模式选择：**

  * 🟢 对多数场景：`General Purpose`
  * 🟢 如果是高并发（多线程大量 I/O）：切换为 `Max I/O` 模式。
* **吞吐量模式：**

  * 🟢 改为 **Provisioned Throughput**（手动设置高一点的 MB/s），不要只用默认的 Burst。

例如：

```bash
Provisioned throughput = 50~100 MB/s
```

---

### ✅ 2. 优化挂载参数（关键）

编辑 `/etc/fstab` 或挂载命令，修改为：

```bash
# 推荐 mount 参数（通过 EFS Mount Helper）
sudo mount -t efs -o tls,nconnect=4,noresvport fs-xxxx:/ /mnt/efs
```

说明：

* `tls`：启用加密通道（优化数据路径）。
* `nconnect=4`：允许客户端并行使用多个 TCP 连接，大幅降低延迟。
* `noresvport`：避免 NFS 端口冲突。
* 如果是 `nfs4` 挂载方式：

  ```bash
  sudo mount -t nfs4 -o nconnect=4,noresvport,rsize=1048576,wsize=1048576 fs-xxxx.efs.ap-east-1.amazonaws.com:/ /mnt/efs
  ```

---

### ✅ 3. 确保同 AZ

EFS 每个 AZ 都有独立的 mount target。
⚠️ 确保 EC2 和 EFS mount target 在同一个 AZ，否则每次 I/O 都要跨 AZ 走公网路径。

```bash
# 检查 EC2 AZ
curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone

# 检查 EFS mount target AZ
aws efs describe-mount-targets --file-system-id fs-xxxx
```

---

### ✅ 4. 加缓存（EFS + local cache）

对于频繁读取的文件，可以在本地加一层缓存，比如：

```bash
# 用 overlayfs 把 EFS 当底层存储
mkdir /mnt/efs /mnt/cache
mount -t overlay overlay -o lowerdir=/mnt/efs,upperdir=/mnt/cache,workdir=/mnt/cache_work /mnt/overlay
```

或者使用 `rsync` 定期同步常用数据，减少频繁 NFS 访问。

---

### ✅ 5. 系统参数调优

```bash
# 提高NFS客户端缓存
echo 15 > /proc/sys/vm/dirty_ratio
echo 5 > /proc/sys/vm/dirty_background_ratio

# 禁止 swap 或调整 swappiness
sudo sysctl vm.swappiness=10
```

---

### ✅ 6. 定期重启/检测卡死防护

既然“以前每天死机 → 升级后变一周死机”，说明**资源是缓解不是根因**。
建议加上 watchdog：

```bash
#!/bin/bash
# /usr/local/bin/check_efs.sh
if [ $(iostat -c | awk '/^avg-cpu/ {getline; print $4}') -gt 50 ]; then
  echo "$(date) high iowait detected, remounting EFS..."
  umount -f /mnt/efs
  mount -a
fi
```

定时执行，防止长期 I/O 堆积导致系统 hang。

---

## 🔍 七、进一步建议

| 方案                                  | 适用场景   | 成本     | 效果            |
| ----------------------------------- | ------ | ------ | ------------- |
| ✅ 优化挂载参数 (`nconnect`, `noresvport`) | 通用     | 免费     | 明显降低 I/O wait |
| ✅ 切换 EFS 模式为 `Max I/O`              | 高并发    | 轻微增加成本 | 提升性能          |
| ✅ 改为 Provisioned Throughput         | 频繁 I/O | 中      | 稳定吞吐          |
| ✅ EC2 同 AZ 挂载                       | 必须     | 免费     | 极大改善          |
| ⚙️ 增加本地缓存层 (overlay/rsync)          | 读多写少   | 中      | 显著改善延迟        |
| ⚙️ 考虑改用 FSx for Lustre 或本地 EBS      | 数据密集型  | 高      | 最佳性能          |

---

要我帮你看具体的挂载配置与 EFS 模式吗？
你可以贴出以下命令结果（脱敏后）：

```bash
mount | grep efs
aws efs describe-file-systems --file-system-id fs-xxxx
aws efs describe-mount-targets --file-system-id fs-xxxx
```

我可以帮你判断瓶颈是在**EFS配置**还是**网络挂载参数**上。

references

https://docs.aws.amazon.com/zh_cn/efs/latest/ug/whatisefs.html