降低AWS EFS的性能

Question

我们已经在aws ec2上使用自动缩放和EFS托管了我们的wordpress网站。但是，PermittedThroughput突然变得接近零字节，BurstCreditBalance变得越来越少（从2TB到几Mbs！）。 EFS大小只有2GB左右！我们第二次面临这个问题。我想知道是否有人对这种情况有类似的经验或任何建议。计划在即将到来的日子从EFS转移到NFS或glusterfs。

Answer 1

  

随着文件系统的增长，Amazon EFS上的吞吐量也随之增加。

     

...

     

文件系统的突发能力（在时间长度和突发速率方面）与其大小直接相关。较大的文件系统可能会在较长时间内以较大的速率突发。因此，如果您的应用程序需要更多爆发（即，如果您发现文件系统的爆发信用额度不足），则应增加文件系统的大小。

     

注意

     

没有使用Amazon EFS进行配置，因此要使文件系统更大，您需要向其添加更多数据。

     

http://docs.aws.amazon.com/efs/latest/ug/performance.html

您提到您的文件系统仅存储2 GiB数据。这就是问题：乍一看它是违反直觉的，但EFS实际上得到更快，因为它变得更大 ......反过来也是如此。小文件系统仅以每存储GiB数据50 KiB /秒的速率累积突发信用。

因此，对于2 GiB文件系统，您将通过每天传输非常少量的数据来耗尽您的积分：

60 sec/minute ×
60 min/hour ×
24 hr/day ×
0.05 MiB/s per GiB stored ×
2 GiB stored = 8,640 MiB/day

所以每天大约8.6 GiB 是这个文件系统可以承受的所有数据传输。

在您记得每月仅支付0.60美元之前，这似乎很奇怪。

只需存储更多数据，即可线性提升性能。用于计算的文件系统大小每小时更新一次，因此如果你走这条路线，你会在几个小时内看到一个上升。

直到现在它运作良好的原因是每个新文件系统都带有相当于2.1 TiB的初始信用余额。这主要是为了让文件系统在您最初将数据加载到文件系统时速度很快，但是在总体存储环境较低的情况下（如您描述的那个），它会持续数天或数周然后突然（显然）最终看到系统稳定到正确的基线行为。

基本上，您要为两个互连参数的设置付费 - 总存储容量和基线吞吐量 - 这两者都不是您配置的。如果您想要更多存储空间，只需存储更多文件......如果您想要更多吞吐量，只需...存储更多文件。