BERND KUHLEN所有笔记 ↗Amazon EFS 问题可能早在显现之前就已经存在。小型文件系统可以成功地为工作负载提供数周或数月的服务，同时消耗有限的突发积分储备。应用程序看起来很健康，仪表板保持绿色，架构赢得了信任。然后，储备量达到零，相同的工作量会遇到低得多的可持续吞吐量上限。
这种延迟使故障感觉突然发生。从操作上讲，这绝非突然。
隐藏的不匹配
利用突增吞吐量，基准吞吐量随存储在 EFS 标准存储类中的数据量而增长。AWS 记录的基准速率为每 GiB 50 KiB/s，每个文件系统至少接收 1 MiB/s 的计量吞吐量。低于基准的工作会获得积分；高于基准的工作会消耗积分。
危险模式是工作负载的长期平均值略高于该基线。这可能不会立即造成事故，因为先前累积的积分可以弥补差额。但是，余额每天都在下降。
为什么症状指向错误的方向
当存储调用花费更长的时间时，应用程序工作人员会等待。在 Linux 上，在不间断的 I/O 等待中受阻的进程会影响平均负载，因此存储瓶颈可能类似于计算容量问题。即使 CPU 使用率不是根本原因，请求队列、工作池已满和超时也会分散在服务中。
如果每个新工作人员针对同一个受限的共享文件系统生成更多请求，则添加实例会使情况变得更糟。瓶颈是共享的，而额外的并发性则增加了其压力。
为什么健康的六个月证明微乎其微
长期无故障只能验证该期间的需求、基准吞吐量和剩余积分的组合。这并不能证明学分用完后工作量是可持续的。A下降了 BurstCreditBalance 因此，它不仅仅是容量细节；它是一个早期的可靠性信号。
负载测试必须涵盖稳定状态，而不仅仅是短暂的峰值测试。十分钟的测试可能会证明爆破上限足够高。它几乎没有说明累积超过数千小时的赤字。
更好的调查顺序
- 将 CPU 利用率与平均负载和 I/O 等待进行比较。
- 检查 EFS
BurstCreditBalance持续数周或数月。 - 比较
MeteredIOBytes和PermittedThroughput. - 将存储限制与应用程序延迟和工作线程饱和度相关联。
- 检查标准存储类别中实际有多少数据，因为这推动了突增基准。
- 确定工作负载属于突增吞吐量、弹性吞吐量还是预置吞吐量。
工程课
突发容量是缓冲区，不是容量计划。任何基于信用的服务都应根据余额的方向和比率进行评估，而不仅仅是根据当前价值是否高于零来评估。本系列前面的文章详细描述了真实的事件模式；下一篇文章将该课程转化为具体的 CloudWatch 监控设计。