降低AWS EFS的性能

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

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的初始信用额度余额.这主要是为了让文件系统在您最初将数据加载到文件系统时速度很快,但是在总体存储环境较低的情况下(如您描述的那个),它将持续数天或数周,然后突然(显然)最终看到系统稳定到正确的基线行为.

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