Мы разместили наш сайт wordpress на aws ec2 с автоматическим масштабированием и EFS, но внезапно PermittedThroughput стал почти нулевым, а BurstCreditBalance день ото дня становился все меньше (с 2 ТБ до нескольких МБ!). Размер EFS был всего около 2 ГБ !. Мы сталкиваемся с этой проблемой второй раз. Я хотел бы знать, есть ли у кого-нибудь подобный опыт или какие-либо предложения по этой ситуации. Планируется переход с EFS на NFS или glusterfs в ближайшие дни.
Снижение производительности AWS EFS
Ответы (2)
Пропускная способность Amazon EFS увеличивается по мере роста файловой системы.
...
Возможности пакетной передачи (как по продолжительности, так и по скорости передачи) файловой системы напрямую зависят от ее размера. Файловые системы большего размера могут разорваться с большей скоростью в течение более длительных периодов времени. Следовательно, если вашему приложению необходимо увеличить количество пакетов (то есть, если вы обнаружите, что в вашей файловой системе заканчиваются кредиты пакетной передачи), вам следует увеличить размер файловой системы.
Примечание
Amazon EFS не поддерживает подготовку к работе, поэтому для увеличения размера файловой системы необходимо добавить в нее больше данных.
Вы упомянули, что ваша файловая система хранит только 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 ТиБ. Это в первую очередь предназначено для того, чтобы файловая система работала быстро, когда вы изначально загружаете в нее данные, но в среде с низким общим объемом хранения, такой как та, которую вы описываете, она будет длиться несколько дней или недель, а затем внезапно (очевидно) вы, наконец, увидеть, как система вернется к своему правильному базовому поведению.
По сути, вы платите за настройку двух взаимосвязанных параметров - общей емкости хранилища и базовой пропускной способности - ни один из которых вы не настраиваете. Если вам нужно больше места для хранения, просто сохраните больше файлов ... а если вам нужна большая пропускная способность, просто ... сохраните больше файлов.
Здесь немного поздно на вечеринку.
TL; DR
Чтобы увеличить общую базовую пропускную способность, создайте фиктивные данные, чтобы увеличить размер файловой системы. Это позволит улучшить базовую производительность и увеличить производительность вашей файловой системы.
Есть два соображения:
- Стоимость ГБ зависит от региона, но цена составляет около 0,30–0,36 доллара США за ГБ (как 2018 г.)
- По мере увеличения размера файловой системы также увеличиваются другие показатели, такие как совокупная пропускная способность пакета, максимальная длительность пакета и% времени, в течение которого файловая система может загружаться (в день). МНЕНИЕ: Мне нравится получать файловые системы размером около 256+ ГБ.
Показатели эффективности:
- Базовая совокупная пропускная способность
- Взрывная совокупная пропускная способность
- Максимальная длительность серийной съемки
- % времени, в течение которого файловая система может взорваться (в день)
Ознакомьтесь с документацией по производительности, чтобы узнать больше о том, как работают прибавки. для каждой метрики.
На сервере, отличном от 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 на размер вашей файловой системы, который вам нужен.
Вы также можете сделать следующее:
- При использовании Elastic Beanstalk создайте распределение CloudFront для балансировщика нагрузки.
- Удалите ненужные плагины из WordPress
- Установите кеширование (OPCache) для Apache или Nginx
В CloudWatch есть панель управления для EFS, если вы решите подключить ее. В нем есть все показатели, необходимые для понимания производительности вашей файловой системы.