Verschlechterung der Leistung von AWS EFS

Wir haben unsere WordPress-Site auf aws ec2 mit automatischer Skalierung und EFS gehostet. Aber plötzlich wurde der PermittedThroughput fast null Bytes und BurstCreditBalance wurde von Tag zu Tag weniger (von 2 TB auf wenige Mbs!). Die EFS-Größe betrug nur etwa 2 GB!. Wir stehen vor diesem Problem zum zweiten Mal. Ich würde gerne wissen, ob es jemanden gibt, der ähnliche Erfahrungen oder Vorschläge zu dieser Situation hat. Ich plane, in den kommenden Tagen von EFS zu NFS oder Glusterfs zu wechseln.

Der Durchsatz auf Amazon EFS skaliert mit dem Wachstum eines Dateisystems.

…

Die Bursting-Fähigkeit (sowohl hinsichtlich Zeitdauer als auch Burst-Rate) eines Dateisystems steht in direktem Zusammenhang mit seiner Größe. Größere Dateisysteme können über längere Zeiträume mit höheren Raten platzen. Wenn Ihre Anwendung mehr Burst benötigen (d. h. wenn Sie feststellen, dass Ihr Dateisystem keine Burst-Credits mehr hat), sollten Sie daher die Größe Ihres Dateisystems erhöhen.

Notiz

Es gibt keine Bereitstellung mit Amazon EFS, also müssen Sie mehr Daten hinzufügen, um Ihr Dateisystem zu vergrößern.

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

Sie haben erwähnt, dass Ihr Dateisystem nur 2 GiB an Daten speichert. Das ist das Problem: Es ist auf den ersten Blick kontraintuitiv, aber EFS wird es tatsächlich Schneller wie es kommt größer… und das Gegenteil ist auch der Fall. Kleine Dateisysteme akkumulieren Burst-Credits nur mit einer Rate von 50 KiB/s pro Sekunde pro GiB gespeicherter Daten.

Für ein 2-GiB-Dateisystem werden Sie also Ihre Credits erschöpfen, indem Sie täglich eine sehr kleine Datenmenge übertragen:

60 sec/minute ×
60 min/hour ×
24 hr/day ×
0.05 MiB/s per GiB stored ×
2 GiB stored = 8,640 MiB/day

Also etwa 8,6 GiB pro Tag ist die gesamte Datenübertragung, die dieses Dateisystem aufrechterhalten kann.

Das erscheint seltsam, bis Sie sich daran erinnern, dass Sie nur 0,60 $ pro Monat zahlen.

Sie können die Leistung linear steigern, indem Sie einfach mehr Daten speichern. Die für die Berechnung verwendete Dateisystemgröße wird einmal pro Stunde aktualisiert. Wenn Sie also diesen Weg gehen, sollten Sie innerhalb weniger Stunden einen Anstieg sehen.

Der Grund, warum es bisher gut funktioniert hat, ist, dass jedes neue Dateisystem mit einem Anfangsguthaben von 2,1 TiB ausgestattet ist. Dies soll in erster Linie ermöglichen, dass das Dateisystem schnell ist, wenn Sie anfänglich Daten darauf laden, aber in einer Umgebung mit geringem Gesamtspeicher wie der von Ihnen beschriebenen dauert es Tage oder Wochen und dann plötzlich (anscheinend) Sie schließlich sehen, wie sich das System auf sein korrektes Grundlinienverhalten einpendelt.

Im Wesentlichen zahlen Sie für die Einstellungen zweier miteinander verbundener Parameter – Gesamtspeicherkapazität und Basisdurchsatz –, die Sie beide nicht konfigurieren. Wenn Sie mehr Speicherplatz benötigen, speichern Sie einfach mehr Dateien … und wenn Sie mehr Durchsatz wünschen, speichern Sie einfach … mehr Dateien.

Etwas spät zur Party hier.

TL;DR

Um Ihren aggregierten Basisdurchsatz zu erhöhen, generieren Sie Dummy-Daten, um die Größe Ihres Dateisystems zu erhöhen. Dies ermöglicht eine bessere Baseline- und Burst-Performance Ihres Dateisystems.

Es gibt zwei Überlegungen:

1. Die Kosten pro GB variieren je nach Region, aber Preis liegt bei etwa 0,30 $ – 0,36 $ pro GB (Stand 2018)
2. Mit zunehmender Dateisystemgröße steigen auch andere Metriken wie Burst-Gesamtdurchsatz, maximale Burst-Dauer und % der Zeit, in der das Dateisystem platzen kann (pro Tag). MEINUNG: Ich mag Dateisysteme um die 256+ GB.

Leistungskennzahlen:

1. Aggregierter Baseline-Durchsatz
2. Burst-Gesamtdurchsatz
3. Maximale Burst-Dauer
4. % der Zeit, in der das Dateisystem platzen kann (pro Tag)

Sehen Sie sich die Leistungsdokumentation an um mehr darüber zu erfahren, wie die Erhöhungen für jede Metrik funktionieren.

Auf Nicht-Windows-Servern können Sie das folgende Skript verwenden, um Dummy-Daten zu generieren, um die Größe Ihres Dateisystems zu erhöhen:

#!/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

Wenn Sie beabsichtigen, dieses Skript von einer EC2-Instance aus auszuführen, auf der das EFS-Dateisystem gemountet ist, empfehle ich, eine EC2-Instance mit hoher Netzwerkleistung zu verwenden. Dies wird dazu beitragen, die zum Generieren von Dateien erforderliche Zeit für diejenigen zu reduzieren, die unter Zeitdruck stehen.

Rufen Sie das Skript auf mit: create.sh 256 “/mnt/efs-directory/dummy”

HINWEIS: Wenn Sie den obigen Befehl ausführen, werden Sie 256 Dateien mit 1 GB pro Stück generieren. Wenn Sie eine kleinere oder größere Datenmenge haben möchten, ändern Sie einfach 256 auf die gewünschte Größe Ihres Dateisystems.

Einige andere Dinge, die Sie tun können, sind:

1. Generieren Sie bei Verwendung von Elastic Beanstalk eine CloudFront-Verteilung für den Load Balancer
2. Entfernen Sie unnötige Plugins aus WordPress
3. Installieren Sie Caching (OPCache) für Apache oder Nginx

Es ist ein Dashboard für EFS in CloudWatch verfügbar, falls Sie dies wünschen Heb es auf. Es verfügt über alle Metriken, die Sie benötigen sollten, um die Leistung Ihres Dateisystems zu verstehen.