Снижение производительности AWS EFS

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

cloudwatch graphp

введите описание изображения здесь


person jobycxa    schedule 16.01.2017    source источник
comment
Нет смысла переходить на собственный NFS или glusterfs, использующие EBS. Как указывает намек @Michael о хранении большего количества файлов, вы можете просто поместить несколько огромных фиктивных файлов в хранилище EFS, чтобы увеличить пропускную способность.   -  person mootmoot    schedule 16.01.2017


Ответы (2)


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

...

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

Примечание

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

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

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

Итак, для файловой системы 2 ГиБ вы собираетесь исчерпать свои кредиты, передавая очень небольшой объем данных ежедневно:

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 ТиБ. Это в первую очередь предназначено для того, чтобы файловая система работала быстро, когда вы изначально загружаете в нее данные, но в среде с низким общим объемом хранения, такой как та, которую вы описываете, она будет длиться несколько дней или недель, а затем внезапно (очевидно) вы, наконец, увидеть, как система вернется к своему правильному базовому поведению.

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

person Michael - sqlbot    schedule 16.01.2017

Здесь немного поздно на вечеринку.

TL; DR

Чтобы увеличить общую базовую пропускную способность, создайте фиктивные данные, чтобы увеличить размер файловой системы. Это позволит улучшить базовую производительность и увеличить производительность вашей файловой системы.


Есть два соображения:

  1. Стоимость ГБ зависит от региона, но цена составляет около 0,30–0,36 доллара США за ГБ (как 2018 г.)
  2. По мере увеличения размера файловой системы также увеличиваются другие показатели, такие как совокупная пропускная способность пакета, максимальная длительность пакета и% времени, в течение которого файловая система может загружаться (в день). МНЕНИЕ: Мне нравится получать файловые системы размером около 256+ ГБ.

Показатели эффективности:

  1. Базовая совокупная пропускная способность
  2. Взрывная совокупная пропускная способность
  3. Максимальная длительность серийной съемки
  4. % времени, в течение которого файловая система может взорваться (в день)

Ознакомьтесь с документацией по производительности, чтобы узнать больше о том, как работают прибавки. для каждой метрики.

На сервере, отличном от Windows, вы можете использовать следующий сценарий для создания фиктивных данных для увеличения размера файловой системы:

#!/bin/bash 
COUNTER=0
while [ $COUNTER -lt $1 ]; do
    # Use DD to generate 1MB of data 1024 times from /dev/zero and add the newly created file to $2/N.txt
    dd if=/dev/zero of=$2/$COUNTER.txt bs=1048576 count=1024
    echo "Added file ${COUNTER}.txt to ${2}/"
    ((COUNTER++))
done

# Save this file as create.sh
# Be sure to run: sudo chmod +x create.sh

Если вы собираетесь запустить этот сценарий из экземпляра EC2 с смонтированной на нем файловой системой EFS, я рекомендую использовать экземпляр EC2 с высокой сетевой производительностью. Это поможет сократить время, необходимое для создания файлов для тех, у кого не хватает времени.

Вызовите сценарий, используя: create.sh 256 "/ mnt / efs-directory / dummy".

ПРИМЕЧАНИЕ. Выполнение вышеуказанной команды означает, что вы создадите 256 файлов размером 1 ГБ за штуку. Если вы хотите иметь больший или меньший объем данных, просто измените 256 на размер вашей файловой системы, который вам нужен.


Вы также можете сделать следующее:

  1. При использовании Elastic Beanstalk создайте распределение CloudFront для балансировщика нагрузки.
  2. Удалите ненужные плагины из WordPress
  3. Установите кеширование (OPCache) для Apache или Nginx

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

person curtismorte    schedule 10.05.2018