AWS EFS的性能下降 [英] Degrading Performance of AWS EFS

问题描述

我们将wordpress网站托管在具有自动缩放功能和EFS的aws ec2上，但是突然之间，PermittedThroughput接近零字节，而BurstCreditBalance越来越少(从2TB到几Mb！). EFS大小仅为2GB！我们第二次面对这个问题.我想知道是否有人对此情况有类似的经验或有什么建议.计划在即将到来的日子从EFS迁移到NFS或glusterfs.

We have hosted our wordpress site on aws ec2 with autoscaling and EFS.But all of a sudden the PermittedThroughput became near Zero bytes and BurstCreditBalance was becoming less day by day(from 2TB to few Mbs!). EFS size was only around 2GB!. We are facing this issue second time. I would like to know is there anyone who has similiar experience or any suggestion on this situation.Planning to move from EFS to NFS or glusterfs on comming days.

推荐答案

Amazon EFS的吞吐量随着文件系统的增长而扩展.

Throughput on Amazon EFS scales as a file system grows.

...

文件系统的爆发能力(无论是时间长度还是突发速率)都与其大小直接相关.较大的文件系统可能会以较大的速率爆发更长的时间.因此，如果您的应用程序需要更多的突发数据(即，如果您发现文件系统用完了突发信用)，则应增加文件系统的大小.

The bursting capability (both in terms of length of time and burst rate) of a file system is directly related to its size. Larger file systems can burst at larger rates for longer periods of time. Therefore, if your application needs to burst more (that is, if you find that your file system is running out of burst credits), you should increase the size of your file system.

注意

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

There’s no provisioning with Amazon EFS, so to make your file system larger you need to add more data to it.

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

您提到您的文件系统仅存储2 GiB数据.这就是问题所在:乍一看这是违反直觉的，但是EFS实际上随着更大而变得更快更快……而事实恰恰相反.小型文件系统仅以每GiB数据每秒50 KiB/秒的速度累积突发信用.

You mentioned that your filesystem is only storing 2 GiB of data. That's the problem: it's counterintuitive at first glance, but EFS actually gets faster as it gets larger... and the opposite is also true. Small filesystems accumulate burst credits only at the rate of 50 KiB/sec per second per GiB of data stored.

因此，对于2 GiB文件系统，您将通过每天传输少量数据来耗尽您的信用:

So, for a 2 GiB filesystem, you're going to deplete your credits by transferring a very small amount of data daily:

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 是该文件系统可以维持的所有数据传输.

So about 8.6 GiB per day is all the data transfer this filesystem can sustain.

这似乎很奇怪，直到您记住您每月只需支付0.60美元.

This seems odd until you remember that you're only paying $0.60 per month.

您可以通过简单地存储更多数据来线性地提高性能.用于计算的文件系统大小每小时更新一次，因此，如果采用这种方式，则在几个小时之内应该会看到一个上升趋势.

You can boost the performance linearly by simply storing more data. The filesystem size that is used for the calculation is updated once per hour, so if you go this route, within a couple of hours you should see an uptick.

之所以能一直有效的原因是，每个新文件系统都具有相当于2.1 TiB的初始信用余额.这主要是为了使文件系统在最初向其加载数据时速度很快，但是在总存储量较低的环境(如您所描述的环境)中，它将持续数天或数周，然后突然(显然)您最终看到系统稳定下来以达到其正确的基准行为.

The reason it's worked well until now is that each new filesystem comes with an initial credit balance equivalent to 2.1 TiB. This is primarily intended to allow the filesystem to be fast as you're initially loading data onto it, but in a low total storage environment such as the one you describe, it will last for days or weeks and then suddenly (apparently) you finally see the system settle down to its correct baseline behavior.

从本质上讲，您需要为两个相互关联的参数(总存储容量和基准吞吐量)的设置付费，而这两者都不是您要配置的.如果您想要更多的存储空间，只需存储更多文件...，如果您想要更多的吞吐量，只需...存储更多文件.

Essentially, you are paying for the settings of two interconnected parameters -- total storage capacity and baseline throughput -- neither of which is something you configure. If you want more storage, just store more files... and if you want more throughput, just... store more files.

这篇关于AWS EFS的性能下降的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！