

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Leistungsspezifikationen von Amazon EFS
<a name="performance"></a>

Die folgenden Abschnitte geben einen Überblick über Amazon-EFS-Leistung und wie sich Ihre Dateisystemkonfiguration auf wichtige Leistungsdimensionen auswirkt. Wir bieten auch einige wichtige Tipps und Empfehlungen zur Optimierung der Leistung Ihres Dateisystems.

**Topics**
+ [Zusammenfassung der Leistung](#performance-overview)
+ [Speicherklassen](#storage-perf)
+ [Leistungsmodi](#performancemodes)
+ [Durchsatzmodi](#throughput-modes)
+ [Tipps zur Amazon-EFS-Leistung](performance-tips.md)
+ [Behebung von Amazon EFS-Leistungsproblemen](troubleshooting-efs-general.md)
+ [Beheben von AMI- und Kernel-Problemen](troubleshooting-efs-ami-kernel.md)

## Zusammenfassung der Leistung
<a name="performance-overview"></a>

Die Dateisystemleistung wird in der Regel anhand der Dimensionen Latenz, Durchsatz und Input/Output Operationen pro Sekunde (IOPS) gemessen. Die Leistung von Amazon EFS in diesen Dimensionen hängt von der Konfiguration Ihres Dateisystems ab. Die folgenden Konfigurationen wirken sich auf die Leistung eines Amazon-EFS-Dateisystems aus:
+ **Dateisystemtyp** – Regional oder One Zone
+ **Leistungsmodus** – Allzweck oder Max. E/A
**Wichtig**  
Der Modus Max I/O Performance hat höhere Latenzen pro Vorgang als der Allzweck-Performance-Modus. Für eine schnellere Leistung empfehlen wir, immer den Allzweck-Leistungsmodus zu verwenden. Weitere Informationen finden Sie unter [Leistungsmodi](#performancemodes).
+ **Durchsatzmodus** – Elastic, Bereitgestellt oder Bursting

In der folgenden Tabelle sind die Leistungsspezifikationen für Dateisysteme, die den Allzweck-Leistungsmodus verwenden, sowie die möglichen unterschiedlichen Kombinationen von Dateisystemtyp und Durchsatzmodus aufgeführt.


**Leistungsspezifikationen für Dateisysteme, die den Allzweck-Leistungsmodus verwenden**  

| Konfiguration von Speicher und Durchsatz | Latenz 1 | Maximale IOPS | Maximaler Durchsatz | 
| --- |--- |--- |--- |
|  ** Dateisystemtyp **  |  ** Durchsatzmodus **  |  **Lesevorgänge**  |  **Schreibvorgänge**  |  **Lesevorgänge**  |  **Schreibvorgänge**  |  **P er-file-system liest** 2  |  **P er-file-system schreibe** 2  |  **Lesen/Schreiben pro Client**  | 
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
|  **Regional**  | Elastic |  \$11 Millisekunde (ms)  | \$12,7 Millisekunden (ms) | 900.000—2.500.000 3 | **500.000 3** |  20—60 Gibibyte pro Sekunde () GiBps  |  1—5 GiBps  |  1.500 Mebibyte pro Sekunde (4) MiBps  | 
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
|  **Regional**  | Bereitgestellt |  \$11 ms  | \$12,7 ms | 55.000 | 25,000 |  3—10 GiBps  |  1—3,33 GiBps  | 500 MiBps | 
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
|  **Regional**  | Bursting |  \$11 ms  | \$12,7 ms | 35 000 | 7.000 |  3—5 GiBps  |  1—3 GiBps  | 500 MiBps | 
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
|  **One Zone**  | Elastisch, bereitgestellt, explosionsartig |  \$11 ms  |  \$11,6 ms  | 35 000 | 7.000 |  3 5 GiBps  |  1 GiBps 5  | 500 MiBps | 
| --- |--- |--- |--- |--- |--- |--- |--- |--- |

1. Die angegebenen Latenzwerte stellen eine optimale Leistung unter optimalen Bedingungen dar. Die tatsächlichen Ergebnisse können je nach Netzwerk, Arbeitslast und Systemfaktoren variieren.

1. Der maximale Lese- und Schreibdurchsatz hängt von der AWS-Region ab. Ein Durchsatz, der den maximalen Durchsatz AWS-Region von an überschreitet, erfordert eine Erhöhung der Durchsatzquote. Jede Anfrage nach zusätzlichem Durchsatz wird vom Amazon EFS-Serviceteam auf case-by-case Basis geprüft. Die Genehmigung kann von Ihrer Art des Workloads abhängen. Weitere Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter [Amazon EFS-Kontingente](limits.md).

1. Standardmäßig bieten Dateisysteme, die Elastic Throughput verwenden, maximal 90.000 Lese-IOPS für selten aufgerufene Daten, 250.000 Lese-IOPS für häufig abgerufene Daten und 50.000 Schreib-IOPS. Wenn Ihr Workload mehr IOPS benötigt, können Sie eine Erhöhung um das bis zu 10-fache dieser Zahlen beantragen. Weitere Informationen finden Sie unter [Amazon-EFS-Kontingente, die Sie erhöhen können](limits.md#soft-limits). Es gelten zusätzliche Empfehlungen, um maximale IOPS zu erreichen. Weitere Informationen finden Sie unter [Optimierung von Workloads, die einen hohen Durchsatz und IOPS erfordern](performance-tips.md#recs-intensive-workloads). 

1. Der maximale kombinierte Lese- und Schreibdurchsatz beträgt 1.500 MiBps für Dateisysteme, die Elastic Throughput verwenden und mit Version 2.0 oder höher des Amazon EFS-Clients (amazon-efs-utils Version) oder des Amazon EFS CSI-Treibers (aws-efs-csi-driver) gemountet wurden. Für alle anderen Dateisysteme liegt das Durchsatzlimit bei 500 MiBps. Weitere Informationen zum Amazon EFS-Client finden Sie unter[Den Amazon EFS-Client installieren](using-amazon-efs-utils.md).

1. One-Zone-Dateisysteme, die Bursting-Durchsatz verwenden, können den gleichen per-file-system Lese- und Schreibdurchsatz erzielen wie regionale Dateisysteme, die Bursting-Durchsatz verwenden (maximal 5 Lesevorgänge GiBps für Lese- und 3 GiBps Schreibvorgänge).

## Speicherklassen
<a name="storage-perf"></a>

Amazon-EFS-Speicherklassen sind je nach Anwendungsfall für die effektivste Speicherung konzipiert.
+ Die EFS-Standard-Speicherklasse verwendet Solid-State-Drive-Speicher (SSD), um die geringste Latenz für häufig aufgerufene Dateien zu gewährleisten. Diese Speicherklasse bietet Latenzen im ersten Byte von nur 1 Millisekunde für Lesevorgänge und 2,7 Millisekunden für Schreibvorgänge.
+ Die Speicherklassen EFS Infrequent Access (IA) und EFS Archive speichern Daten, auf die seltener zugegriffen wird, für die nicht die Latenzleistung erforderlich ist, die für häufig abgerufene Daten erforderlich ist. Diese Speicherklassen bieten Latenzen im ersten Byte von mehreren zehn Millisekunden.

Weitere Informationen über EFS-Speicherklassen finden Sie unter [EFS-Speicherklassen](features.md#storage-classes). 

## Leistungsmodi
<a name="performancemodes"></a>

Amazon EFS bietet zwei Leistungsmodi: Allzweck und Max. E/A. 
+ Der **Allzweckmodus** hat die niedrigste Latenz pro Vorgang und ist der Standardleistungsmodus für Dateisysteme. One-Zone-Dateisysteme verwenden immer den Allzweck-Leistungsmodus. Für eine schnellere Leistung empfehlen wir, immer den Allzweck-Leistungsmodus zu verwenden.
+ ** I/O Der Max-Modus** ist ein Performance-Typ der vorherigen Generation, der für stark parallelisierte Workloads konzipiert wurde, die höhere Latenzen tolerieren können als der Allzweckmodus. I/O Der Max-Modus wird für One Zone-Dateisysteme oder Dateisysteme, die Elastic Throughput verwenden, nicht unterstützt.
**Wichtig**  
Aufgrund der höheren Latenzen pro Vorgang beim Modus „Max. E/A“ empfehlen wir, für alle Dateisysteme den Allzweckleistungsmodus zu verwenden.

Um sicherzustellen, dass Ihr Workload innerhalb der IOPS-Grenze bleibt, die für Dateisysteme verfügbar ist, die den allgemeinen Leistungsmodus verwenden, können Sie die `PercentIOLimit` CloudWatch Metrik überwachen. Weitere Informationen finden Sie unter [CloudWatch Metriken für Amazon EFS](efs-metrics.md).

Anwendungen können ihre IOPS elastisch bis zu dem mit dem Leistungsmodus verbundenen Grenzwert skalieren. IOPS werden Ihnen nicht separat in Rechnung gestellt; sie sind in der Durchsatzabrechnung eines Dateisystems enthalten. Jede NFS-Anfrage (Network File System) wird als Durchsatz von 4 Kilobyte (KB) oder als tatsächliche Anfrage- und Antwortgröße berechnet, je nachdem, welcher Wert größer ist.

## Durchsatzmodi
<a name="throughput-modes"></a>

Der Durchsatzmodus eines Dateisystems bestimmt den Durchsatz, der Ihrem Dateisystem zur Verfügung steht. Amazon EFS bietet drei Durchsatzmodi: Elastic, Bereitgestellt und Bursting. Der Lesedurchsatz wird reduziert, damit Sie einen höheren Lese- als Schreibdurchsatz erzielen können. Der maximale Durchsatz, der in jedem Durchsatzmodus verfügbar ist, hängt von der AWS-Region ab. Weitere Informationen zum maximalen Dateisystemdurchsatz in den verschiedenen Regionen finden Sie unter [Amazon EFS-Kontingente](limits.md). 

Ihr Dateisystem kann zusammen einen Lese- und Schreibdurchsatz von 100 % erreichen. Wenn Ihr Dateisystem beispielsweise 33 % seines Limits für den Lesedurchsatz ausnutzt, kann das Dateisystem gleichzeitig bis zu 67 % seines Limits für den Schreibdurchsatz erreichen. Sie können die Durchsatzauslastung Ihres Dateisystems im Diagramm **Durchsatzauslastung (%)** auf der Seite mit den **Dateisystemdetails** der Konsole überwachen. Weitere Informationen finden Sie unter [Überwachung der Durchsatzleistung](how_to_use_metrics.md#monitor-throughput-performance).

### Auswählen des richtigen Durchsatzmodus für ein Dateisystem
<a name="choosing"></a>

Die Wahl des richtigen Durchsatzmodus für Ihr Dateisystem hängt von den Leistungsanforderungen Ihres Workloads ab.
+ **Elastischer Durchsatz** (empfohlen) — Verwenden Sie den standardmäßigen Elastic Throughput, wenn Sie hohe oder unvorhersehbare Workloads haben und Leistungsanforderungen haben, die schwer vorherzusagen sind, oder wenn Ihre Anwendung den Durchsatz mit einem average-to-peak Verhältnis von 5% oder weniger steigert. Weitere Informationen finden Sie unter [Elastischer Durchsatz](#elastic). 
+ **Bereitgestellter Durchsatz** — Verwenden Sie den bereitgestellten Durchsatz, wenn Sie die Leistungsanforderungen Ihres Workloads kennen oder wenn Ihre Anwendung den Durchsatz mit einem average-to-peak Verhältnis von 5% oder mehr steigert. Weitere Informationen finden Sie unter [Bereitgestellter Durchsatz](#provisioned-throughput).
+ **Bursting-Durchsatz** — Verwenden Sie den Bursting-Durchsatz, wenn Sie einen Durchsatz wünschen, der mit der Speichermenge in Ihrem Dateisystem skaliert.

  Wenn Sie nach der Verwendung des Bursting-Durchsatzes feststellen, dass Ihre Anwendung durch den Durchsatz eingeschränkt ist (sie verwendet beispielsweise mehr als 80% des zulässigen Durchsatzes oder Sie haben alle Ihre Burst-Credits aufgebraucht), sollten Sie entweder Elastic oder Provisioned Throughput verwenden. Weitere Informationen finden Sie unter [Bursting-Durchsatz](#bursting).

 Weitere Informationen zu Amazon-EFS-Metriken finden Sie unter [CloudWatch Metriken für Amazon EFS](efs-metrics.md).

### Elastischer Durchsatz
<a name="elastic"></a>

Für Dateisysteme, die Elastic Throughput verwenden, skaliert Amazon EFS die Durchsatzleistung automatisch nach oben oder unten, um den Anforderungen Ihrer Workload-Aktivität gerecht zu werden. Elastischer Durchsatz ist der beste Durchsatzmodus für hohe oder unvorhersehbare Workloads mit Leistungsanforderungen, die schwer vorherzusagen sind, oder für Anwendungen, bei denen der Durchsatz im Durchschnitt bei 5% oder weniger des Spitzendurchsatzes liegt (das average-to-peak Verhältnis).

Da die Durchsatzleistung für Dateisysteme mit Elastic Throughput automatisch skaliert wird, müssen Sie die Durchsatzkapazität nicht spezifizieren oder bereitstellen, um Ihre Anwendungsanforderungen zu erfüllen. Sie zahlen nur für die Menge der gelesenen oder geschriebenen Metadaten und Daten, und Sie sammeln oder verbrauchen bei der Nutzung von Elastic Throughput keine zusätzlichen Credits.

**Anmerkung**  
Elastic Throughput ist zwar darauf ausgelegt, elastisch mit Ihrem Durchsatz zu skalieren, wir empfehlen jedoch, im Rahmen Ihrer betrieblichen Best Practices eine angemessene Steuerung durch Monitoring-Metriken mit CloudWatch (gemessenenIOBytes) und Nutzungswarnungen zu implementieren. Dies hilft Ihnen dabei, eine optimale Ressourcennutzung aufrechtzuerhalten und Ihre geplanten Betriebsparameter einzuhalten. Weitere Informationen finden Sie unter [Metriken mit Amazon überwachen CloudWatch](monitoring-cloudwatch.md).

Informationen zu den Elastic-Durchsatzgrenzwerten pro Region finden Sie unter[Amazon-EFS-Kontingente, die Sie erhöhen können](limits.md#soft-limits).

### Bereitgestellter Durchsatz
<a name="provisioned-throughput"></a>

Mit Provisioned Throughput geben Sie einen Durchsatz an, den das Dateisystem unabhängig von der Größe oder dem hohen Guthabenstand des Dateisystems erreichen kann. Verwenden Sie den bereitgestellten Durchsatz, wenn Sie die Leistungsanforderungen Ihres Workloads kennen oder wenn Ihre Anwendung den Durchsatz um 5% oder mehr des average-to-peak Verhältnisses erhöht.

Bei Dateisystemen, die den bereitgestellten Durchsatz verwenden, wird Ihnen der für das Dateisystem aktivierte Durchsatz in Rechnung gestellt. Der in einem Monat in Rechnung gestellte Durchsatzbetrag basiert auf dem bereitgestellten Durchsatz, der den in Ihrem Dateisystem enthaltenen Basisdurchsatz aus dem Standardspeicher übersteigt, bis zu den geltenden Limits für den Bursting-Basisdurchsatz in der AWS-Region. 

Wenn der Basisdurchsatz des Dateisystems den bereitgestellten Durchsatz überschreitet, wird automatisch der für das Dateisystem zulässige Bursting-Durchsatz verwendet (bis zu den jeweils geltenden Grenzwerten für den Bursting-Baseline-Durchsatz). AWS-Region

Informationen zu den pro Region bereitgestellten Durchsatzgrenzwerten finden Sie unter. [Amazon-EFS-Kontingente, die Sie erhöhen können](limits.md#soft-limits) 

#### Bursting-Durchsatz
<a name="bursting"></a>

Ein Bursting-Durchsatz wird für Workloads empfohlen, bei denen ein Durchsatz erforderlich ist, der mit der Speichermenge in Ihrem Dateisystem skaliert. Beim Bursting-Durchsatz ist der Basisdurchsatz proportional zur Größe des Dateisystems in der Standard-Speicherklasse, und zwar mit einer Rate von 50 KiBps pro GiB Speicher. Burst-Guthaben fallen an, wenn das Dateisystem weniger als die Basisdurchsatzrate verbraucht, und werden abgezogen, wenn der Durchsatz die Basisrate überschreitet. 

Wenn Burst-Credits verfügbar sind, kann ein Dateisystem einen Durchsatz von bis zu 100 MiBps pro TiB im Standardspeicher (50 KiBps pro GiB) bis zum AWS-Region Limit von mindestens 100 MiBps erhöhen. Wenn keine Burst-Credits verfügbar sind, kann ein Dateisystem bis zu 50 MiBps pro TiB Speicherplatz speichern, mindestens jedoch 1. MiBps

Informationen zum Bursting-Durchsatz pro Region finden Sie unter. [General resource quotas that cannot be changed](limits.md#ResourceHardLimits) 

##### Wissenswertes zu Amazon-EFS-Burst-Guthaben
<a name="efs-burst-credits"></a>

Beim Bursting-Durchsatz sammelt jedes Dateisystem im Laufe der Zeit Burst-Credits mit einer Basisrate, die von der Größe des Dateisystems bestimmt wird, das in der EFS-Standard-Speicherklasse gespeichert ist. Die Basisrate beträgt 50 MiBps pro Tebibyte [TiB] Speicher (entspricht 50 KiBps pro GiB Speicher). Amazon EFS misst Lesevorgänge bis zu einem Drittel der Rate von Schreibvorgängen, sodass das Dateisystem eine Basisrate von bis zu 150 KiBps pro GiB Lesedurchsatz oder 50 KiBps pro GiB Schreibdurchsatz erreichen kann.

Ein Dateisystem kann den Durchsatz kontinuierlich mit seiner gemessenen Basisrate erhöhen. Ein Dateisystem sammelt immer dann Burst-Guthaben an, wenn es inaktiv ist oder den Durchsatz unter die gemessene Basisrate treibt. Gesammelte Burst-Gutschriften ermöglichen dem Dateisystem, den Durchsatz über die Grundrate hinaus zu erhöhen.

Beispielsweise hat ein Dateisystem mit 100 GiB an gemessenen Daten in der Standardspeicherklasse einen Basisdurchsatz von 5. MiBps ****Über einen Zeitraum von 24 Stunden Inaktivität erhält das Dateisystem Guthaben im Wert von 432.000 MiB (5 MiB **×** 86.400 Sekunden **=** 432.000 MiB), das verwendet werden kann, um 72 Minuten MiBps lang bei 100 zu bursten (432.000 MiB ÷100 = 72 Minuten). MiBps **** 

Dateisysteme, die größer als 1 TiB sind, können stets für bis zu 50 % der Zeit ein Bursting ausführen, wenn sie über die verbleibenden 50 % der Zeit inaktiv sind.

 Die folgende Tabelle enthält Beispiele für das Bursting-Verhalten.


****  

| Größe des Dateisystems | Bursting-Durchsatz | Basisdurchsatz | 
| --- | --- | --- | 
| 100 GiB gemessener Daten im Standardspeicher |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/efs/latest/ug/performance.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/efs/latest/ug/performance.html)  | 
| 1 TiB gemessener Daten im Standardspeicher |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/efs/latest/ug/performance.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/efs/latest/ug/performance.html)  | 
| 10 TiB gemessener Daten im Standardspeicher |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/efs/latest/ug/performance.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/efs/latest/ug/performance.html)  | 
| Im Allgemeinen größere Dateisysteme |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/efs/latest/ug/performance.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/efs/latest/ug/performance.html)  | 

**Anmerkung**  
Amazon EFS bietet einen gemessenen Durchsatz von 1 MiBps für alle Dateisysteme, auch wenn die Basisrate niedriger ist.  
Die Größe des Dateisystems, die für die Ermittlung der Basisrate und der Burst-Rate verwendet wird, ist die gemessene `ValueInStandard`-Größe, die über die [DescribeFileSystems](API_DescribeFileSystems.md)-API-Operation verfügbar ist.  
Dateisysteme unter 1 TiB können Gutschriften bis zu einer Höhe von maximal 2,1 TiB erwerben. Dateisysteme über 1 TiB können Gutschriften bis zu einer Höhe von 2,1 TiB pro gespeichertem TiB erwerben. Dieses Verhalten bedeutet, dass Dateisysteme genügend Guthaben ansammeln können, um ein kontinuierliches Bursting über bis zu 12 Stunden auszuführen.

### Einschränkungen beim Umschalten des Durchsatzes und beim Ändern der bereitgestellten Menge
<a name="switch-throughput-mode"></a>

Sie können den Durchsatzmodus eines vorhandenen Dateisystems wechseln und die Durchsatzmenge ändern. Nach dem Umschalten des Durchsatzmodus auf Bereitgestellter Durchsatz oder der Änderung der Menge des bereitgestellten Durchsatzes sind die folgenden Aktionen jedoch für einen Zeitraum von 24 Stunden eingeschränkt:
+ Wechsel vom Modus „Bereitgestellter Durchsatz“ in den Durchsatzmodus „Elastic“ oder „Bursting“. 
+ Verringerung der Menge des bereitgestellten Durchsatzes.

# Tipps zur Amazon-EFS-Leistung
<a name="performance-tips"></a>

Berücksichtigen Sie bei der Verwendung von Amazon EFS die folgenden Tipps zur Leistung:

## Durchschnittliche I/O Größe
<a name="efs-perf-avg-io-size"></a>

Die verteilte Struktur von Amazon EFS unterstützt einen hohen Grad an Verfügbarkeit, Beständigkeit und Skalierbarkeit. Diese verteilte Architektur führt zu einer geringfügigen Latenz bei den einzelnen Dateivorgängen. Aufgrund dieser Latenz pro Vorgang steigt der Gesamtdurchsatz im Allgemeinen mit steigender I/O Durchschnittsgröße, da sich der Overhead bei einer größeren Datenmenge amortisiert.

## Optimierung von Workloads, die einen hohen Durchsatz und IOPS erfordern
<a name="recs-intensive-workloads"></a>

Verwenden Sie für Workloads, die einen hohen Durchsatz und hohe IOPS erfordern, regionale Dateisysteme, die mit dem allgemeinen Leistungsmodus und dem elastischen Durchsatz konfiguriert sind.

**Anmerkung**  
Um die maximale Anzahl an Lese-IOPS für Daten zu erreichen, auf die häufig zugegriffen wird, muss das Dateisystem Elastic Throughput verwenden.

Um ein Höchstmaß an Leistung zu erzielen, müssen Sie die Parallelisierung nutzen, indem Sie Ihre Anwendung oder Ihren Workload wie folgt konfigurieren.

1. Verteilen Sie den Workload gleichmäßig auf alle Clients und Verzeichnisse, wobei die Anzahl der Verzeichnisse mindestens der Anzahl der verwendeten Clients entspricht.

1. Minimieren Sie Konflikte, indem Sie einzelne Threads unterschiedlichen Datensätzen oder Dateien zuordnest.

1. Verteilen Sie die Arbeitslast auf 10 oder mehr NFS-Clients mit mindestens 64 Threads pro Client in einem einzigen Mount-Ziel.

## Gleichzeitige Verbindungen
<a name="efs-perf-sim-connections"></a>

Sie können Amazon EFS-Dateisysteme auf bis zu Tausenden von Amazon EC2- und anderen AWS Recheninstanzen gleichzeitig mounten. Sie können einen höheren Durchsatz in Ihrem Dateisystem über alle Datenverarbeitungs-Instances hinweg erzielen, wenn Sie Ihre Anwendung über mehrere Instances hinweg parallelisieren können.

## Anforderungsmodell
<a name="efs-perf-request-model"></a>

Wenn Sie asynchrone Schreibvorgänge zu Ihrem Dateisystem aktivieren, werden ausstehende Schreibvorgänge auf der Amazon-EC2-Instance gepuffert, bevor sie asynchron zu Amazon EFS geschrieben werden. Asynchrone Schreibvorgänge besitzen in der Regel niedrigere Latenzen. Bei der Ausführung asynchroner Schreibvorgänge verwendet der Kernel zusätzlichen Speicher zum Zwischenspeichern. 

Ein Dateisystem, für das synchrone Schreibvorgänge aktiviert wurden oder das Dateien mittels einer Option öffnet, die den Zwischenspeicher umgeht (z. B. `O_DIRECT`), gibt synchrone Anforderungen an Amazon EFS aus. Jede Operation durchläuft einen Umlauf zwischen dem Client und Amazon EFS.

**Anmerkung**  
Ihr Anforderungsmodell geht hinsichtlich Konsistenz (wenn Sie mehrere Amazon-EC2-Instances verwenden) und Geschwindigkeit Kompromisse ein. Die Verwendung synchroner Schreibvorgänge sorgt für mehr Datenkonsistenz, da jede Schreibanforderungstransaktion abgeschlossen wird, bevor die nächste Anforderung verarbeitet wird. Durch die Verwendung asynchroner Schreibvorgänge wird der Durchsatz erhöht, da ausstehende Schreibvorgänge zwischengespeichert werden.

## NFS-Client-Mount-Einstellungen
<a name="efs-perf-nfs-client-mnt-settings"></a>

Überprüfen Sie, ob Sie die empfohlenen Mount-Optionen wie in [Mounting von EFS-Dateisystemen](mounting-fs.md) und [Überlegungen zur Installation für Linux](mounting-fs-mount-cmd-general.md) beschrieben verwenden. 

Beim Mounten Ihrer Dateisysteme auf Amazon-EC2-Instances unterstützt Amazon EFS die Network File System-Version 4.0 und 4.1 (NFSv4)-Protokolle. NFSv4.1 bietet im Vergleich zu NFSv4.0 (weniger als 1 000 Dateien pro Sekunde) eine bessere Leistung für parallel Lesevorgänge kleiner Dateien (mehr als 10 000 Dateien pro Sekunde). Für Amazon EC2 macOS-Instances, auf denen macOS Big Sur ausgeführt wird, wird nur NFSv4 2.0 unterstützt.

Verwenden Sie nicht die folgenden Mount-Optionen:
+ `noac`, `actimeo=0`, `acregmax=0`, `acdirmax=0` – Diese Optionen deaktivieren den Attribut-Cache, was sich sehr negativ auf die Leistung auswirkt.
+ `lookupcache=pos`, `lookupcache=none` – Diese Optionen deaktivieren den Dateinamen-Nachschlage-Cache, was sich sehr negativ auf die Leistung auswirkt.
+ `fsc` – Diese Option aktiviert das lokale Zwischenspeichern von Dateien, ändert jedoch nichts an der Kohärenz des NFS-Cache und verringert auch nicht die Latenzen.

**Anmerkung**  
Sie sollten Sie die Größe der Puffer für Lese- und Schreibpuffer für Ihren NFS-Client auf 1 MB erhöhen, wenn Sie Ihr Dateisystem mounten.

## Optimierung der Leistung kleiner Dateien
<a name="optimize-open-close"></a>

Sie können die Leistung kleiner Dateien verbessern, indem Sie das erneute Öffnen von Dateien minimieren, die Parallelität erhöhen und Referenzdateien nach Möglichkeit bündeln.
+ Minimieren Sie die Anzahl der Roundtrips zum Server.

  Schließen Sie Dateien nicht unnötig, wenn Sie sie später in einem Workflow benötigen. Wenn Sie Dateideskriptoren geöffnet lassen, können Sie direkt auf die lokale Kopie im Cache zugreifen. Operationen zum Öffnen und Schließen von Dateien und zum Schließen von Metadaten können im Allgemeinen nicht asynchron oder über eine Pipeline ausgeführt werden.

  Beim Lesen oder Schreiben kleiner Dateien sind die beiden zusätzlichen Roundtrips von Bedeutung.

  Jeder Roundtrip (Datei öffnen, Datei schließen) kann genauso viel Zeit in Anspruch nehmen wie das Lesen oder Schreiben von Megabyte an Massendaten. Es ist effizienter, eine Eingabe- oder Ausgabedatei zu Beginn Ihres Datenverarbeitungsauftrag einmal zu öffnen und sie für die gesamte Dauer des Auftrags geöffnet zu lassen.
+ Verwenden Sie Parallelität, um die Auswirkungen von Roundtrip-Zeiten zu reduzieren.
+ Bündeln Sie Referenzdateien in einer `.zip`-Datei. Einige Anwendungen verwenden eine große Menge kleiner, meist schreibgeschützter Referenzdateien. Wenn Sie diese in einer `.zip`-Datei bündeln, können Sie viele Dateien in einem Roundtrip durch Öffnen und Schließen lesen.

  Das `.zip`-Format ermöglicht den wahllosen Zugriff auf einzelne Dateien.

## Optimieren der Verzeichnisleistung
<a name="optimize-directories"></a>

Wenn ein Listing (**ls**) für sehr große Verzeichnisse (über 100k Dateien) durchgeführt wird, die gleichzeitig geändert werden, können Linux-NFS-Clients hängen bleiben und keine Antwort zurückgeben. Dieses Problem wurde in Kernel 5.11 behoben, der auf die Amazon-Linux 2-Kernel 4.14, 5.4 und 5.10 portiert wurde.

Wir empfehlen, die Anzahl der Verzeichnisse in Ihrem Dateisystem möglichst auf weniger als 10 000 zu beschränken. Verwenden Sie so weit wie möglich verschachtelte Unterverzeichnisse.

Vermeiden Sie beim Auflisten eines Verzeichnisses die Angabe von Dateiattributen, wenn diese nicht erforderlich sind, da sie nicht im Verzeichnis selbst gespeichert sind.

## Optimierung der NFS-Größe von read\$1ahead\$1kb
<a name="efs-perf-optimize-nfs-read-ahead"></a>

Das `read_ahead_kb`-NFS-Attribut definiert die Anzahl der Kilobyte, die der Linux-Kernel bei einem sequentiellen Lesevorgang vorab lesen oder vorab abrufen muss. 

Bei Linux-Kernel-Versionen vor 5.4.\$1 wird der Wert `read_ahead_kb` durch Multiplikation von `NFS_MAX_READAHEAD` mit dem Wert für `rsize` (der vom Client konfigurierten Lesepuffergröße, die in den Mount-Optionen festgelegt wurde) festgelegt. Bei Verwendung der [empfohlenen Mount-Optionen](mounting-fs-mount-cmd-general.md) setzt diese Formel `read_ahead_kb` auf 15 MB. 

**Anmerkung**  
Ab den Linux-Kernel-Versionen 5.4.\$1 verwendet der Linux-NFS-Client einen `read_ahead_kb`-Standardwert von 128 KB. Wir empfehlen, diesen Wert auf 15 MB zu erhöhen.

Die Amazon-EFS-Mountinghilfe, die in `amazon-efs-utils`-Version 1.33.2 und höher verfügbar ist, ändert den `read_ahead_kb`-Wert nach dem Mounten des Dateisystems automatisch auf 15 \$1 `rsize` oder 15 MB.

Wenn Sie bei Linux-Kernel 5.4 oder höher die Mountinghilfe nicht zum Mounten Ihrer Dateisysteme verwenden, sollten Sie erwägen, `read_ahead_kb` manuell auf 15 MB einzustellen, um die Leistung zu verbessern. Nach dem Mounten des Dateisystems können Sie den `read_ahead_kb`-Wert mithilfe des folgenden Befehls zurücksetzen. Ersetzen Sie die folgenden Werte, bevor Sie diesen Befehl verwenden:
+ Ersetzen Sie `read-ahead-value-kb` durch die gewünschte Größe in Kilobyte.
+ Ersetzen Sie `efs-mount-point` durch den Mountingpunkt des Dateisystems.

```
device_number=$(stat -c '%d' efs-mount-point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo read-ahead-value-kb > /sys/class/bdi/$major:$minor/read_ahead_kb"
```

Im Folgenden wird beispielsweise die `read_ahead_kb`-Größe auf 1 MB festgelegt.

```
device_number=$(stat -c '%d' efs)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo 15000 > /sys/class/bdi/$major:$minor/read_ahead_kb"
```

# Behebung von Amazon EFS-Leistungsproblemen
<a name="troubleshooting-efs-general"></a>

 Wenn Sie Probleme mit Amazon EFS haben, die sich nur schwer beheben lassen, sollten Sie sicherstellen, dass Sie einen aktuellen Linux-Kernel verwenden. Wenn Sie eine Linux-Unternehmensdistribution verwenden, empfehlen wir Folgendes:
+ Amazon Linux 2 mit Kernel 4.3 oder neuer
+ Amazon Linux 2015.09 oder neuer
+ RHEL 7.3 oder neuer
+ Alle Versionen von Ubuntu 16.04
+ Ubuntu 14.04 mit Kernel 3.13.0-83 oder neuer
+ SLES 12 Sp2 oder höher

Wenn Sie eine andere Verteilung oder einen benutzerdefinierten Kernel verwenden, empfehlen wir Kernel-Version 4.3 oder neuer.

**Anmerkung**  
RHEL 6.9 könnte für bestimmte Workloads suboptimal sein aufgrund von [Schlechte Leistung beim Öffnen vieler Dateien gleichzeitig](#open-close-operations-serialized).

**Topics**
+ [Ein EFS-Dateisystem kann nicht erstellt werden](#cant-create-filesystem)
+ [Zugriff auf zulässige Dateien im NFS-Dateisystem verweigert](#nfs-16-group-limit)
+ [Fehler beim Zugriff auf die Amazon-EFS-Konsole](#efs-console-access-errors)
+ [Amazon EC2-Instance hängt sich auf](#ec2-instance-hangs)
+ [Anwendung, die große Datenmengen schreibt, bleibt hängen](#application-large-data-hangs)
+ [Schlechte Leistung beim Öffnen vieler Dateien gleichzeitig](#open-close-operations-serialized)
+ [Benutzerdefinierte NFS-Einstellungen verursachen Schreibverzögerungen](#custom-nfs-settings-write-delays)
+ [Die Erstellung von Sicherungen mit Oracle Recovery Manager ist langsam](#oracle-backup-slow)

## Ein EFS-Dateisystem kann nicht erstellt werden
<a name="cant-create-filesystem"></a>

Eine Anfrage zur Erstellung eines EFS-Dateisystems schlägt mit der folgenden Meldung fehl:

```
User: arn:aws:iam::111122223333:user/username is not authorized to
perform: elasticfilesystem:CreateFileSystem on the specified resource.
```

**Maßnahme**  
Überprüfen Sie Ihre AWS Identity and Access Management (IAM-) Richtlinie, um sicherzustellen, dass Sie berechtigt sind, EFS-Dateisysteme mit den angegebenen Ressourcenbedingungen zu erstellen. Weitere Informationen finden Sie unter [Identitäts- und Zugriffsmanagement für Amazon EFS](security-iam.md).

## Zugriff auf zulässige Dateien im NFS-Dateisystem verweigert
<a name="nfs-16-group-limit"></a>

Wenn ein Benutzer, dem mehr als 16 Zugriffsgruppen IDs (GIDs) zugewiesen sind, versucht, einen Vorgang in einem NFS-Dateisystem auszuführen, kann ihm der Zugriff auf zulässige Dateien im Dateisystem verweigert werden. [Dieses Problem tritt auf, weil das NFS-Protokoll maximal 16 GIDs pro Benutzer unterstützt und alle weiteren Daten aus der NFS-Client-Anfrage gekürzt GIDs werden, wie in RFC 5531 definiert.](https://www.rfc-editor.org/rfc/rfc5531)

**Maßnahme**  
Strukturieren Sie Ihre NFS-Benutzer- und Gruppenzuordnungen neu, sodass jedem Benutzer nicht mehr als 16 Zugriffsgruppen () zugewiesen werden. GIDs 

## Fehler beim Zugriff auf die Amazon-EFS-Konsole
<a name="efs-console-access-errors"></a>

Dieser Abschnitt beschreibt Fehler, die beim Zugriff auf die Amazon-EFS-Management Console auftreten können.

### Fehler bei der Authentifizierung der Anmeldeinformationen für `ec2:DescribeVPCs`
<a name="efs-console-access-error-ec2"></a>

Die folgende Fehlermeldung wird beim Zugriff auf die Amazon-EFS-Konsole angezeigt:

```
AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.
```

Dieser Fehler weist darauf hin, dass Ihre Anmeldeinformationen beim Amazon EC2-Service nicht erfolgreich authentifiziert wurden. Die Amazon-EFS-Konsole ruft den Amazon EC2-Service in Ihrem Namen auf, wenn Sie EFS-Dateisysteme in der von Ihnen ausgewählten VPC erstellen.

**Maßnahme**  
Stellen Sie sicher, dass die Uhrzeit auf dem Client, der auf die Amazon-EFS-Konsole zugreift, korrekt eingestellt ist.

## Amazon EC2-Instance hängt sich auf
<a name="ec2-instance-hangs"></a>

Eine Amazon EC2-Instance kann hängen bleiben, weil Sie ein Mounting-Ziel für ein Dateisystem gelöscht haben, ohne das Dateisystem vorher auszuhängen. 

**Maßnahme**  
Bevor Sie ein Dateisystem-Mounting-Ziel löschen, heben Sie das Mounting des Dateisystems auf. Weitere Informationen zum Unmounten Ihres Amazon-EFS-Dateisystems finden Sie unter [Aufheben des Mountings von Dateisystemen](unmounting-fs.md).

## Anwendung, die große Datenmengen schreibt, bleibt hängen
<a name="application-large-data-hangs"></a>

Eine Anwendung, die eine große Menge an Daten in Amazon EFS schreibt, hängt sich auf und verursacht einen Neustart der Instance.

**Maßnahme**

Wenn eine Anwendung zu lange braucht, um alle Daten in Amazon EFS zu schreiben, kann es sein, dass Linux neu startet, weil es den Anschein hat, dass der Vorgang nicht mehr reagiert. Diese Verhaltensweise wird von zwei Kernel-Konfigurationsparametern definiert, `kernel.hung_task_panic` und `kernel.hung_task_timeout_secs`.

Im folgenden Beispiel wird der Status des hängengebliebenen Prozesses vom `ps`- Befehl mit `D` vor dem Neustart der Instance gemeldet; dies bedeutet, dass der Prozess auf einen E/A-Vorgang wartet.

```
$ ps aux | grep large_io.py
root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py
/efs/large_file
```

Um einen Neustart zu verhindern, verlängern Sie den Timeout-Zeitraum, oder deaktivieren Sie die Kernel-Panik, wenn eine Aufgabe hängenbleibt. Der folgende Befehl deaktiviert die Kernel-Panik für hängengebliebene Aufgaben in den meisten Linux-Systemen.

```
$ sudo sysctl -w kernel.hung_task_panic=0
```

## Schlechte Leistung beim Öffnen vieler Dateien gleichzeitig
<a name="open-close-operations-serialized"></a>

Bei Anwendungen, die mehrere Dateien parallel öffnen, wird die erwartete Leistungssteigerung durch I/O Parallelisierung nicht erreicht.

**Maßnahme**

Dieses Problem tritt auf Network File System Version 4 (NFSv4) -Clients und auf RHEL 6-Clients auf, die NFSv4 .1 verwenden, weil diese NFS-Clients die NFS OPEN- und CLOSE-Operationen serialisieren. Verwenden Sie das NFS-Protokoll Version 4.1 und eine der vorgeschlagenen [Linux-Distributionen](#recommend.linux.dist), die dieses Problem nicht haben.

Wenn Sie NFSv4 .1 nicht verwenden können, beachten Sie, dass der Linux 4.0-Client NFSv4 Öffnungs- und Schließanfragen nach Benutzer-ID und Gruppe serialisiert. IDs Diese Serialisierung geschieht auch dann, wenn mehrere Prozesse oder mehrere Threads gleichzeitig Anforderungen ausgeben. Der Client sendet jeweils nur einen Öffnungs- oder Schließvorgang an einen NFS-Server, wenn alle übereinstimmen. IDs Um diese Probleme zu umgehen, können Sie eine der folgenden Aktionen durchführen:
+ Sie können jeden Vorgang von einer anderen Benutzer-ID auf derselben Amazon EC2-Instance ausführen.
+ Sie können IDs den Benutzer für alle offenen Anfragen unverändert lassen und IDs stattdessen die Gruppe ändern.
+ Sie können jeden Vorgang auf einer separaten Amazon EC2-Instance ausführen.

## Benutzerdefinierte NFS-Einstellungen verursachen Schreibverzögerungen
<a name="custom-nfs-settings-write-delays"></a>

Sie haben benutzerdefinierte NFS-Client-Einstellungen, und es dauert bis zu drei Sekunden, bis eine Amazon EC2-Instance einen Schreibvorgang auf einem Dateisystem von einer anderen Amazon EC2-Instance sieht.

**Maßnahme**

Wenn dieses Problem auftritt, können Sie sie auf eine der folgenden Weisen lösen:
+ Wenn der NFS-Client auf der Amazon EC2-Instance, die die Daten liest, das Attribut-Caching aktiviert hat, unmounten Sie Ihr Dateisystem. Mounten Sie es dann erneut mit der Option `noac`, um die Attributzwischenspeicherung zu deaktivieren. Das Zwischenspeichern von Attributen in NFSv4 .1 ist standardmäßig aktiviert.
**Anmerkung**  
Die Deaktivierung der clientseitigen Zwischenspeicherung kann möglicherweise die Leistung Ihrer Anwendung beeinträchtigen.
+ Sie können auch bei Bedarf den Attributzwischenspeicher leeren, indem Sie eine mit den NFS-Vorgängen kompatible Computersprache verwenden. Zu diesem Zweck können Sie `ACCESS`-Vorgangsanforderung unmittelbar vor einer Leseanforderung senden.

   Beispielsweise können Sie mit der Programmiersprache Python den folgenden Aufruf konstruieren.

  ```
  # Does an NFS ACCESS procedure request to clear the attribute cache, given a path to the file
  import os
  os.access(path, os.W_OK)
  ```

## Die Erstellung von Sicherungen mit Oracle Recovery Manager ist langsam
<a name="oracle-backup-slow"></a>

Die Erstellung von Sicherungen mit Oracle Recovery Manager kann langsam sein, wenn Oracle Recovery Manager für 120 Sekunden pausiert, bevor er einen Sicherungsauftrag startet.

**Maßnahme**

Wenn dieses Problem auftritt, deaktivieren Sie Oracle Direct NFS, wie unter [Enabling and Disabling Direct NFS Client Control of NFS](https://docs.oracle.com/database/122/HPDBI/enabling-and-disabling-direct-nfs-client-control-of-nfs.htm) im Oracle Help Center beschrieben.

**Anmerkung**  
Amazon EFS unterstützt kein Oracle Direct NFS.

# Beheben von AMI- und Kernel-Problemen
<a name="troubleshooting-efs-ami-kernel"></a>

Nachfolgend finden Sie Informationen zur Fehlerbehebung bei Problemen im Zusammenhang mit bestimmten Amazon Machine Image (AMI) oder Kernel-Versionen bei der Verwendung von Amazon EFS von einer Amazon EC2-Instance aus.

**Topics**
+ [Eigentümerschaft kann nicht geändert werden](#chown-kernal)
+ [Aufgrund des Client-Bug wiederholt das Dateisystem Vorgänge immer wieder](#file-system-stuck-client-bug)
+ [Blockierter Client](#deadlocked-client)
+ [Das Auflisten von Dateien in einem großen Verzeichnis dauert zu lange](#long-time-listing)

## Eigentümerschaft kann nicht geändert werden
<a name="chown-kernal"></a>

Sie können den Besitzer eines nicht file/directory mit dem `chown` Linux-Befehl ändern.

**Kernel-Versionen mit diesem Bug**  
2.6.32

**Maßnahme**

Sie können dieses Problem lösen, indem Sie folgende Schritte ausführen: 
+ Wenn Sie `chown` für den einmaligen Einrichtungsschritt durchführen, der zur Änderung der Eigentümerschaft des EFS-Stammverzeichnisses erforderlich ist, können Sie den Befehl `chown` von einer Instance ausführen, auf der ein neuer Kernel ausgeführt wird. Verwenden Sie zum Beispiel die neueste Version von Amazon Linux.
+ Wenn `chown` Teil Ihrer Produktionsabläufe ist, müssen Sie die Kernel-Version aktualisieren, um `chown` zu verwenden.

## Aufgrund des Client-Bug wiederholt das Dateisystem Vorgänge immer wieder
<a name="file-system-stuck-client-bug"></a>

Aufgrund eines Client-Bugs wiederholt ein Dateisystem ständig Vorgänge.

**Maßnahme**  
Aktualisieren Sie die Client-Software auf die neueste Version.

## Blockierter Client
<a name="deadlocked-client"></a>

Ein Client ist blockiert.

**Kernel-Versionen mit diesem Bug**
+ CentOS-7 mit Kernel Linux 3.10.0-229.20.1.el7.x86\$164
+ Ubuntu 15.10 mit Kernel Linux 4.2.0-18-generic

**Maßnahme**  
Führen Sie eine der folgenden Aktionen aus:
+ Upgrade auf eine neuere Kernel-Version. Für CentOS-7 enthält Kernel-Version **Linux 3.10.0-327** oder neuer die Fehlerbehebung.
+ Downgrade auf eine ältere Kernel-Version.

## Das Auflisten von Dateien in einem großen Verzeichnis dauert zu lange
<a name="long-time-listing"></a>

Dies kann geschehen, wenn das Verzeichnis geändert wird, während Ihr NFS-Client das Verzeichnis durchläuft, um den Listenvorgang abzuschließen. Wenn der NFS-Client feststellt, dass die Inhalte des Verzeichnisses während dieses Vorgangs geändert wurden, beginnt er mit dem Vorgang von vorn. Dadurch kann es sein, dass der ls-Befehl für ein großes Verzeichnis mit häufig geänderten Dateien zu lange dauert.

**Kernel-Versionen mit diesem Bug**  
CentOS- und RHEL-Kernel-Versionen unter 2.6.32-696.el6

**Maßnahme**  
Um dieses Problem zu lösen, führen Sie ein Upgrade auf eine neuere Kernel-Version durch.