2017-01-16 3 views
2

Мы разместили наш сайт wordpress на aws ec2 с автомасштабированием и EFS. Но внезапно PermitedThroughput стал близким к байтам Zero, а BurstCreditBalance становилось все меньше с каждым днем ​​(от 2TB до нескольких Mbs!). Размер EFS составлял всего около 2 ГБ !. Мы сталкиваемся с этим вопросом во второй раз. Я хотел бы знать, есть ли кто-нибудь, кто имеет аналогичный опыт или какое-либо предложение в этой ситуации. Планирование перехода от EFS к NFS или glusterfs в дни работы.Деградирующая производительность AWS EFS

cloudwatch graphp

enter image description here

+1

Не имеет смысла перемещаться в собственные NFS или glusterfs, которые используют EBS. Как указывает @Michael, наведите указатель на «сохранить больше файлов», вы можете просто положить несколько огромных файлов-заглушек в свою пропускную способность для хранения EFS. – mootmoot

ответ

5

Производительность на Amazon EFS масштабируется по мере роста файловой системы.

...

Способность разрывной (как с точки зрения длины и времени лопаются скорости) файловой системы напрямую связано с его размером. Большие файловые системы могут лопнуть с большей скоростью в течение более длительных периодов времени. Поэтому, если вашему приложению нужно больше лопнуть (то есть, если вы обнаружите, что в вашей файловой системе не хватает пакетных кредитов), вы должны увеличить размер вашей файловой системы.

Примечание

Там нет инициализации с Amazon EFS, так, чтобы файловая система больше вам нужно добавить больше данных к нему.

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

Вы упомянули, что файловая система только хранить 2 Гб данных. В этом проблема: на первый взгляд это противоречит интуиции, но EFS фактически получает быстрее, так как он получает больше ... и наоборот. Небольшие файловые системы накапливают всплески только со скоростью 50 KiB/sec в секунду на каждую сохраненную информацию.

Таким образом, для 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 Гигабайт в день все передачи данных эта файловая система может поддерживать.

Это кажется странным, пока вы не вспомните, что платите только 0,60 доллара США в месяц.

Вы можете увеличить производительность линейно, просто сохраняя больше данных. Размер файловой системы, который используется для расчета, обновляется один раз в час, поэтому, если вы идете по этому маршруту, через пару часов вы должны увидеть всплывающее окно.

Причина, по которой она до сих пор работала, заключается в том, что каждая новая файловая система имеет первоначальный кредитный баланс, эквивалентный 2,1 TiB. Это прежде всего предназначено для того, чтобы файловая система была быстрой, поскольку вы первоначально загружаете данные на нее, но в условиях низкой общей среды хранения, например, описываемой вами, она будет длиться несколько дней или недель, а затем внезапно (видимо) вы, наконец, см. в системе опуститься до правильного поведения базовой линии.

По сути, вы платите за настройки двух взаимосвязанных параметров - общей емкости хранилища и пропускной способности базовой линии - ни одно из которых не настраивается. Если вам нужно больше памяти, просто сохраните больше файлов ... и если вы хотите увеличить пропускную способность, просто ... сохраните больше файлов.

Смежные вопросы