Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Specifiche prestazionali di Amazon EFS
Le sezioni seguenti forniscono una panoramica delle prestazioni Amazon EFS e descrivono in che modo la configurazione del file system influisce sulle dimensioni prestazionali chiave. Forniamo anche alcuni importanti suggerimenti e raccomandazioni per ottimizzare le prestazioni del tuo file system.
**Topics**
+ [Riepilogo delle prestazioni](#performance-overview)
+ [Classi di archiviazione](#storage-perf)
+ [Modalità prestazionali](#performancemodes)
+ [Modalità di velocità di trasmissione effettiva](#throughput-modes)
+ [Suggerimenti per le prestazioni Amazon EFS](performance-tips.md)
+ [Risoluzione dei problemi di prestazioni di Amazon EFS](troubleshooting-efs-general.md)
+ [Risoluzione dei problemi di AMI e kernel](troubleshooting-efs-ami-kernel.md)
## Riepilogo delle prestazioni
Le prestazioni del file system vengono in genere misurate utilizzando le dimensioni di latenza, velocità effettiva e Input/Output operazioni al secondo (IOPS). Le prestazioni di Amazon EFS in queste dimensioni dipendono dalla configurazione del file system. Le seguenti configurazioni influiscono sulle prestazioni di un file system Amazon EFS:
+ **Tipo di file system**: regionale o a zona singola
+ **Modalità prestazioni**: a scopi generali o I/O max
**Importante**
La modalità Max I/O Performance ha latenze per operazione più elevate rispetto alla modalità a prestazioni General Purpose. Per prestazioni più veloci, si consiglia di utilizzare sempre la modalità di prestazioni a scopi generali. Per ulteriori informazioni, consulta [Modalità prestazionali](#performancemodes).
+ **Modalità Throughput**: Elastic, Provisioned o Bursting
La tabella seguente illustra le specifiche prestazionali per i file system che utilizzano la modalità di prestazioni General Purpose e le possibili diverse combinazioni di tipo di file system e modalità di throughput.
**Specifiche prestazionali per i file system che utilizzano la modalità di prestazioni General Purpose**
| Configurazione dello storage e della velocità di trasmissione effettiva | Latenza 1 | Numero massimo di IOPS | Velocità di trasmissione effettiva massima |
| --- |--- |--- |--- |
| **Tipo di file system** | **Modalità di velocità di trasmissione effettiva** | **Operazioni di lettura** | **Operazioni di scrittura** | **Operazioni di lettura** | **Operazioni di scrittura** | **P er-file-system read** 2 | **P er-file-system scrivi** 2 | **Lettura/scrittura per client** |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
| **Regionale** | Elastic | \$11 millisecondo (ms) | \$12,7 millisecondi (ms) | 900.000—2.500.000 3 | **500.000 3** | 20-60 gibibyte al secondo () GiBps | 1—5 GiBps | 1.500 mebibyte al secondo (4) MiBps |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
| **Regionale** | Assegnata | \$11 ms | \$12,7 ms | 55.000 | 25.000 | 3—10 GiBps | 1—3,33 GiBps | 500 MiBps |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
| **Regionale** | Ottimizzazione | \$11 ms | \$12,7 ms | 35.000 | 7,000 | 3—5 GiBps | 1—3 GiBps | 500 MiBps |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
| **Zona singola** | Elastico, fornito, esplosivo | \$11 ms | \$11,6 ms | 35.000 | 7,000 | 3 5 GiBps | 1 GiBps 5 | 500 MiBps |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |
1. I valori di latenza mostrati rappresentano le prestazioni ottimali in condizioni ottimali. I risultati effettivi possono variare in base alla rete, al carico di lavoro e ai fattori di sistema.
1. La velocità massima di lettura e scrittura dipende da Regione AWS. Un throughput superiore al throughput massimo Regione AWS di un valore richiede un aumento della quota di throughput. Qualsiasi richiesta di throughput aggiuntivo viene presa in considerazione dal case-by-case team di assistenza di Amazon EFS. L'approvazione potrebbe dipendere dal tipo di carico di lavoro. Per ulteriori informazioni sulla richiesta di aumenti di quota, consulta [Quote Amazon EFS](limits.md).
1. Per impostazione predefinita, i file system che utilizzano la velocità effettiva elastica generano un massimo di 90.000 IOPS di lettura per i dati a cui si accede raramente, 250.000 IOPS di lettura per i dati ad accesso frequente e 50.000 IOPS di scrittura. Se il carico di lavoro richiede più IOPS, puoi richiedere un aumento fino a 10 volte questi numeri. Per ulteriori informazioni, consulta [Quote per Amazon EFS che è possibile incrementare](limits.md#soft-limits). Per raggiungere il massimo degli IOPS si applicano raccomandazioni aggiuntive. Per ulteriori informazioni, consulta [Ottimizzazione dei carichi di lavoro che richiedono throughput e IOPS elevati](performance-tips.md#recs-intensive-workloads).
1. Il throughput massimo combinato di lettura e scrittura è 1.500 MiBps per i file system che utilizzano la velocità effettiva elastica e montati utilizzando la versione 2.0 o successiva del client Amazon EFS (amazon-efs-utils versione) o il driver CSI di Amazon EFS (). aws-efs-csi-driver Per tutti gli altri file system, il limite di velocità effettiva è 500. MiBps Per ulteriori informazioni sul client Amazon EFS, consulta[Installazione del client Amazon EFS](using-amazon-efs-utils.md).
1. I file system One Zone che utilizzano la velocità di trasmissione Bursting possono garantire gli stessi livelli di velocità di per-file-system lettura e scrittura dei file system regionali che utilizzano la velocità effettiva di Bursting (lettura massima di 5 GiBps in lettura e 3 in scrittura). GiBps
## Classi di archiviazione
Le classi di storage Amazon EFS sono progettate per lo storage più efficace a seconda dei casi d'uso.
+ La classe di storage EFS Standard utilizza storage SSD (Solid State Drive) per offrire i livelli di latenza più bassi per i file a cui si accede di frequente. Questa classe di storage fornisce latenze di primo byte di appena 1 millisecondo per le letture e 2,7 millisecondi per le scritture.
+ Le classi di storage EFS Infrequent Access (IA) ed EFS Archive archiviano i dati a cui si accede meno frequentemente che non richiedono le prestazioni di latenza richieste dai dati a cui si accede di frequente. Queste classi di storage forniscono latenze di primo byte di decine di millisecondi.
Per ulteriori informazioni sulle classi di storage EFS, consulta [Classi di storage EFS](features.md#storage-classes).
## Modalità prestazionali
Amazon EFS offre due modalità prestazionali: a scopi generali e I/O max.
+ La **modalità General Purpose** ha la latenza per operazione più bassa ed è la modalità di prestazioni predefinita per i file system. I file system One Zone utilizzano sempre la modalità di prestazioni General Purpose. Per prestazioni più veloci, si consiglia di utilizzare sempre la modalità di prestazioni a scopi generali.
+ La ** I/O modalità Max** è un tipo di prestazioni della generazione precedente progettata per carichi di lavoro altamente parallelizzati in grado di tollerare latenze più elevate rispetto alla modalità General Purpose. La I/O modalità Max non è supportata per i file system One Zone o per i file system che utilizzano la velocità effettiva elastica.
**Importante**
A causa delle più elevate latenze per operazione con I/O max, consigliamo di utilizzare la modalità prestazionale a scopi generali per tutti i file system.
Per garantire che il carico di lavoro rimanga entro il limite di IOPS disponibile per i file system che utilizzano la modalità di prestazioni General Purpose, puoi monitorare la metrica. `PercentIOLimit` CloudWatch Per ulteriori informazioni, consulta [CloudWatch metriche per Amazon EFS](efs-metrics.md).
Le applicazioni possono scalare i propri IOPS in modo elastico fino al limite associato alla modalità a prestazioni. Gli IOPS non vengono fatturati separatamente; sono inclusi nella contabilità della velocità di trasmissione effettiva di un file system. Ogni richiesta di Network File System (NFS) viene contabilizzata come 4 kilobyte (KB) di throughput o come dimensione effettiva di richiesta e risposta, a seconda di quale tra i due sia maggiore.
## Modalità di velocità di trasmissione effettiva
La modalità di velocità di trasmissione effettiva del file system determina la velocità di trasmissione effettiva disponibile per il file system. Amazon EFS offre tre modalità di throughput: Elastic, Provisioned e Bursting. La velocità effettiva di lettura è scontata per consentirti di aumentare la velocità di lettura rispetto alla velocità effettiva di scrittura. La velocità effettiva massima disponibile con ciascuna modalità di throughput dipende da Regione AWS. Per ulteriori informazioni sulla velocità effettiva massima del file system nelle diverse regioni, consulta [Quote Amazon EFS](limits.md).
Il file system può raggiungere una velocità combinata del 100% della velocità di lettura e scrittura. Ad esempio, se il file system utilizza il 33% del limite di velocità effettiva di lettura, il file system può raggiungere contemporaneamente fino al 67% del limite di velocità di scrittura. È possibile monitorare l'utilizzo della velocità effettiva del file system nel grafico di **Utilizzo della velocità effettiva (%)** nella pagina **Dettagli del file system** della console. Per ulteriori informazioni, consulta [Monitoraggio delle prestazioni di throughput](how_to_use_metrics.md#monitor-throughput-performance).
### Scelta della modalità di throughput corretta per un file system
La scelta della modalità di throughput corretta per il file system dipende dai requisiti prestazionali del carico di lavoro.
+ **Throughput elastico** (consigliato): utilizza il throughput elastico predefinito in caso di carichi di lavoro con picchi o imprevedibili e requisiti prestazionali difficili da prevedere o quando l'applicazione aumenta il throughput con un rapporto del 5% o inferiore. average-to-peak Per ulteriori informazioni, consulta [Throughput elastico](#elastic).
+ Throughput assegnato: utilizza il **throughput** assegnato se conosci i requisiti prestazionali del tuo carico di lavoro o quando l'applicazione aumenta il throughput con un rapporto del 5% o più. average-to-peak Per ulteriori informazioni, consulta [Throughput allocato](#provisioned-throughput).
+ Throughput **bursting: utilizza Bursting throughput** quando desideri un throughput scalabile in base alla quantità di storage presente nel file system.
Se, dopo aver utilizzato la velocità effettiva di bursting, scopri che la tua applicazione è soggetta a vincoli di throughput (ad esempio, utilizza più dell'80% della velocità effettiva consentita o hai utilizzato tutti i crediti di burst), allora dovresti utilizzare il throughput Elastic o Provisioned. Per ulteriori informazioni, consulta [Velocità effettiva di espansione](#bursting).
Per ulteriori informazioni sulle metriche di Amazon EFS, consulta [CloudWatch metriche per Amazon EFS](efs-metrics.md).
### Throughput elastico
Per i file system che utilizzano la velocità effettiva elastica, Amazon EFS aumenta o riduce automaticamente le prestazioni di throughput per soddisfare le esigenze dell'attività del carico di lavoro. Il throughput elastico è la modalità di throughput migliore per carichi di lavoro con picchi o imprevedibili con requisiti di prestazioni difficili da prevedere o per applicazioni che incrementano il throughput al 5% o meno del throughput di picco in media (il rapporto). average-to-peak
Poiché le prestazioni di throughput per i file system con Elastic Throughput si scalano automaticamente, non è necessario specificare o fornire la capacità di throughput per soddisfare le esigenze delle applicazioni. Paghi solo per la quantità di metadati e dati letti o scritti e non accumuli né utilizzi crediti burst durante l'utilizzo di Elastic Throughput.
**Nota**
Sebbene il throughput elastico sia progettato per adattarsi elasticamente alla velocità effettiva, consigliamo di implementare una governance adeguata attraverso il monitoraggio delle metriche con CloudWatch (MeteredIOBytes) e avvisi di utilizzo come parte delle migliori pratiche operative. Questo ti aiuta a mantenere un utilizzo ottimale delle risorse e a rimanere entro i parametri operativi pianificati. Per ulteriori informazioni, consulta [Monitoraggio delle metriche con Amazon CloudWatch](monitoring-cloudwatch.md).
Per informazioni sui limiti di throughput elastico per regione, vedere. [Quote per Amazon EFS che è possibile incrementare](limits.md#soft-limits)
### Throughput allocato
Con Provisioned Throughput, è possibile specificare un livello di throughput che il file system è in grado di gestire indipendentemente dalle dimensioni del file system o dal saldo del credito residuo. Utilizza Provisioned Throughput se conosci i requisiti prestazionali del tuo carico di lavoro o se la tua applicazione aumenta il throughput al 5% o più del rapporto. average-to-peak
Per i file system che utilizzano il throughput Provisioned, viene addebitata la quantità di throughput abilitata per il file system. L'importo della velocità effettiva fatturata in un mese si basa sulla velocità effettiva fornita in eccesso rispetto alla velocità effettiva di base inclusa nel file system dallo storage Standard, fino ai limiti di throughput di base prevalenti di Bursting previsti in Regione AWS.
Se la velocità effettiva di base del file system supera la quantità di throughput di base di Provisioned, utilizza automaticamente la velocità effettiva di bursting consentita per il file system (fino ai limiti di throughput della linea di base di Bursting prevalenti). Regione AWS
Per informazioni sui limiti di velocità effettiva di [Quote per Amazon EFS che è possibile incrementare](limits.md#soft-limits) Provisioned per regione, vedere.
#### Velocità effettiva di espansione
Il bursting throughput è consigliato per carichi di lavoro che richiedono un throughput scalabile in base alla quantità di storage presente nel file system. Con Bursting Throughput, il throughput di base è proporzionato alla dimensione del file system nella classe di storage Standard, a una velocità di 50 per KiBps ogni GiB di storage. I crediti burst vengono accumulati quando il file system consuma al di sotto della velocità di throughput di base e vengono detratti quando il throughput supera la velocità di base.
Quando sono disponibili crediti burst, un file system può aumentare il throughput fino a 100 per MiBps TiB nello storage Standard (50 per KiBps GiB), fino al Regione AWS limite, con un minimo di 100. MiBps Se non sono disponibili crediti burst, un file system può gestire fino a 50 unità MiBps per TiB di storage, con un minimo di 1. MiBps
Per informazioni sulla velocità effettiva di bursting per regione, consulta. [General resource quotas that cannot be changed](limits.md#ResourceHardLimits)
##### Informazioni sui crediti di burst di Amazon EFS
Con il bursting throughput, ogni file system guadagna crediti burst nel tempo a una velocità di base determinata dalla dimensione del file system archiviato nella classe di storage EFS Standard. La frequenza di base è di 50 MiBps per tebibyte [TiB] di storage (equivalente a 50 KiBps per GiB di storage). Amazon EFS misura le operazioni di lettura fino a un terzo della velocità delle operazioni di scrittura, permettendo al file system di raggiungere una velocità di base fino a 150 per KiBps GiB di velocità effettiva di lettura o 50 per KiBps GiB di velocità effettiva di scrittura.
Un file system può incrementare la velocità effettiva alla velocità misurata di base in modo continuo. Un file system accumula crediti burst ogni volta che è inattivo o porta il throughput al di sotto della velocità misurata di base. I crediti per i burst accumulati offrono al file system la possibilità di incrementare il throughput al di sopra della velocità di base.
Ad esempio, un file system con 100 GiB di dati misurati nella classe di storage Standard ha un throughput di base di 5. MiBps ****In un periodo di inattività di 24 ore, il file system guadagna 432.000 MiB di credito (5 MiB × 86.400 **secondi** = 432.000 **MiB**), che possono essere utilizzati per raggiungere i 100 MiB per 72 minuti (432.000 MiB ÷ 100 = 72 minuti). MiBps MiBps ****
I file system di dimensioni superiori a 1 TiB possono sempre sfruttare dei burst per il 50 per cento del tempo se rimangono inattivi per il restante 50 per cento.
La tabella riportata di seguito fornisce degli esempi di comportamento in tema di burst.
****
| Dimensione del file system | Throughput di burst | Throughput di base |
| --- | --- | --- |
| 100 GiB di dati misurati nello storage Standard | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/efs/latest/ug/performance.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/efs/latest/ug/performance.html) |
| 1 TiB di dati misurati nello storage Standard | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/efs/latest/ug/performance.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/efs/latest/ug/performance.html) |
| 10 TiB di dati misurati nello storage Standard | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/efs/latest/ug/performance.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/efs/latest/ug/performance.html) |
| In genere, file system di dimensioni maggiori | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/efs/latest/ug/performance.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/efs/latest/ug/performance.html) |
**Nota**
Amazon EFS fornisce un throughput misurato pari MiBps a 1 per tutti i file system, anche se la frequenza di base è inferiore.
La dimensione del file system utilizzata per determinare la velocità di base e quella di burst è la stessa dimensione `ValueInStandard` misurata disponibile tramite l'operazione API [DescribeFileSystems](API_DescribeFileSystems.md).
I file system possono guadagnare crediti fino a un saldo massimo di 2,1 TiB per file system di dimensioni inferiori a 1 TiB, o fino a 2,1 TiB per TiB memorizzato in caso di file system di dimensioni superiori a 1 TiB. Questo approccio implica che i file system possano accumulare un numero sufficiente di crediti per aumentare le prestazioni fino a 12 ore in modo continuo.
### Restrizioni al cambio di velocità effettiva e alla modifica della quantità assegnata
È possibile cambiare la modalità di throughput di un file system esistente e modificare la quantità di throughput. Tuttavia, dopo aver cambiato la modalità di throughput in Provisioned Throughput o modificato l'importo del throughput fornito, le seguenti azioni sono limitate per un periodo di 24 ore:
+ Passaggio dalla modalità di throughput Provisioned alla modalità di throughput Elastic o Bursting.
+ Diminuzione della quantità di throughput fornita.
# Suggerimenti per le prestazioni Amazon EFS
Quando si utilizza Amazon EFS, è necessario ricordare i seguenti suggerimenti sulle prestazioni.
## I/O Dimensioni medie
La natura distribuita di Amazon EFS offre alti livelli di disponibilità, durabilità e scalabilità. Grazie all'architettura distribuita, la latenza per ciascuna operazione sui file è minima. A causa di questa latenza per operazione, la velocità effettiva complessiva generalmente aumenta all'aumentare della I/O dimensione media, poiché il sovraccarico viene ammortizzato su una maggiore quantità di dati.
## Ottimizzazione dei carichi di lavoro che richiedono throughput e IOPS elevati
Per carichi di lavoro che richiedono velocità effettiva e IOPS elevati, utilizzate i file system regionali configurati con la modalità prestazionale General Purpose e la velocità effettiva elastica.
**Nota**
Per ottenere il massimo IOPS di lettura per i dati a cui si accede di frequente, il file system deve utilizzare la velocità effettiva elastica.
Per raggiungere i massimi livelli di prestazioni, è necessario sfruttare la parallelizzazione configurando l'applicazione o il carico di lavoro come segue.
1. Distribuisci il carico di lavoro in modo uniforme su tutti i client e le directory, con almeno lo stesso numero di directory del numero di client utilizzati.
1. Riduci al minimo le controversie allineando i singoli thread a set di dati o file distinti.
1. Distribuisci il carico di lavoro su 10 o più client NFS, con almeno 64 thread per client in un unico target di montaggio.
## Connessioni simultanee
Puoi montare i file system Amazon EFS su un massimo di migliaia di Amazon EC2 e altre istanze di AWS elaborazione contemporaneamente. È possibile ottenere livelli di throughput più elevati sul file system in aggregato tra le istanze di elaborazione se si può parallelizzare l'applicazione su più istanze.
## Modello di richiesta
Se si abilitano le scritture asincrone sul file system, le operazioni di scrittura in sospeso vengono bufferizzate sull'istanza Amazon EC2 prima di essere scritte su Amazon EFS in modo asincrono. Le scritture asincrone presentano generalmente delle latenze inferiori. Quando si eseguono delle scritture asincrone, il kernel utilizza della memoria aggiuntiva per la memorizzazione nella cache.
Un file system che ha abilitato le scritture sincrone, o uno che apre i file usando un'opzione che bypassa la cache (ad esempio, `O_DIRECT`), emette richieste sincrone ad Amazon EFS. Ogni operazione implica una richiesta e una risposta tra client ed Amazon EFS.
**Nota**
La modalità di richiesta presenta compromessi in termini di consistenza (se si utilizzano molteplici istanze Amazon EC2) e di velocità. L'utilizzo delle scritture sincrone offre una maggiore coerenza dei dati completando ogni transazione di richiesta di scrittura prima di elaborare la richiesta successiva. L'utilizzo delle scritture asincrone offre una maggiore velocità di trasmissione mediante il buffering delle operazioni di scrittura in sospeso.
## Impostazioni di installazione del client NFS
Verifica di utilizzare le opzioni di montaggio raccomandate come descritto in [Montaggio dei file system EFS](mounting-fs.md) e in [Considerazioni sul montaggio per Linux](mounting-fs-mount-cmd-general.md).
Quando si installano i file system sulle istanze Amazon EC2, Amazon EFS supporta i protocolli Network File System versione 4.0 e 4.1 (NFSv4). NFSv4.1 offre prestazioni migliori per le operazioni di lettura parallela di file di piccole dimensioni (più di 10.000 file al secondo) rispetto a NFSv4.0 (meno di 1.000 file al secondo). Per le istanze macOS di Amazon EC2 che eseguono macOS Big Sur, è supportata solo la versione 2.0. NFSv4
Non utilizzare le seguenti opzioni di installazione:
+ `noac`, `actimeo=0`, `acregmax=0`, `acdirmax=0`: queste opzioni disattivano la cache degli attributi, il che ha un impatto molto importante sulle prestazioni.
+ `lookupcache=pos`, `lookupcache=none`: queste opzioni disattivano la cache di ricerca del nome file, il che ha un impatto molto importante sulle prestazioni.
+ `fsc`: questa opzione abilita la memorizzazione nella cache locale dei file, ma non modifica la coerenza della cache NFS e non riduce le latenze.
**Nota**
Quando si installa il file system, è possibile aumentare le dimensioni del buffer in lettura e in scrittura per il client NFS fino a 1 MB.
## Ottimizzazione delle prestazioni dei file di piccole dimensioni
È possibile migliorare le prestazioni dei file di piccole dimensioni riducendo al minimo le riaperture dei file, aumentando il parallelismo e raggruppando i file di riferimento ove possibile.
+ Riduci al minimo il numero di accessi al server.
Non chiudere inutilmente i file se ne hai bisogno in un secondo momento in un flusso di lavoro. Mantenere aperti i descrittori di file consente l'accesso diretto alla copia locale nella cache. Le operazioni di apertura, chiusura e metadati dei file in genere non possono essere eseguite in modo asincrono o tramite una pipeline.
Quando si leggono o si scrivono file di piccole dimensioni, i due passaggi aggiuntivi sono significativi.
Ogni passaggio (file aperto, file chiuso) può richiedere tanto tempo quanto la lettura o la scrittura di megabyte di dati in blocco. È più efficiente aprire un file di input o output una sola volta, all'inizio del processo di elaborazione, e tenerlo aperto per l'intera durata del lavoro.
+ Utilizza il parallelismo per ridurre l'impatto del tempo di andata e ritorno.
+ Raggruppa i file di riferimento in un file `.zip`. Alcune applicazioni utilizzano un ampio set di file di riferimento di piccole dimensioni, per lo più di sola lettura. Il raggruppamento di questi file in un unico file `.zip` consente di leggere molti file con un solo passaggio di apertura e chiusura.
Il formato `.zip` consente l'accesso casuale a singoli file.
## Ottimizzazione delle prestazioni della directory
Quando si esegue un elenco (**ls**) su directory molto grandi (oltre 100.000 file) che vengono modificate contemporaneamente, i client Linux NFS possono bloccarsi e non restituire una risposta. Questo problema è stato risolto nel kernel 5.11, che è stato portato sui kernel Amazon Linux 2 4.14, 5.4 e 5.10.
Ti consigliamo di mantenere il numero di directory sul file system a meno di 10.000, se possibile. Usa sottodirectory annidate il più possibile.
Quando elenchi una directory, evita di ottenere gli attributi dei file se non sono richiesti, perché non sono memorizzati nella directory stessa.
## Ottimizzazione della dimensione read\$1ahead\$1kb di NFS
L’attributo `read_ahead_kb` NFS definisce il numero di kilobyte per cui il kernel Linux deve effettuare la lettura anticipata o il recupero preliminare durante un'operazione di lettura sequenziale.
Per le versioni del kernel Linux precedenti alla 5.4.\$1, il valore `read_ahead_kb` viene impostato moltiplicando `NFS_MAX_READAHEAD` per il valore `rsize` (la dimensione del buffer di lettura configurata dal client impostata nelle opzioni di montaggio). Quando si utilizzano le [opzioni di montaggio consigliate](mounting-fs-mount-cmd-general.md), questa formula imposta `read_ahead_kb` su 15 MB.
**Nota**
A partire dalle versioni del kernel Linux 5.4.\$1, il client Linux NFS utilizza un valore `read_ahead_kb` predefinito di 128 KB. Si consiglia di aumentare questo valore a 15 MB.
L'helper di montaggio di Amazon EFS disponibile nella versione `amazon-efs-utils` 1.33.2 e successive modifica automaticamente il valore `read_ahead_kb` per renderlo uguale a 15 \$1 `rsize`, o 15 MB, dopo il montaggio del file system.
Per i kernel Linux 5.4 o successivi, se non utilizzi l’helper di montaggio per installare i tuoi file system, valuta la possibilità di impostare `read_ahead_kb` manualmente su 15 MB per migliorare le prestazioni. Dopo aver montato il file system, è possibile reimpostare il valore `read_ahead_kb` utilizzando il comando seguente. Prima di usare questo comando, sostituisci i seguenti valori:
+ Sostituisci `read-ahead-value-kb` con la dimensione desiderata in kilobyte.
+ Sostituisci `efs-mount-point` con il punto di montaggio del file system.
```
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"
```
Ad esempio, di seguito viene impostata la dimensione `read_ahead_kb` su 15 MB.
```
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"
```
# Risoluzione dei problemi di prestazioni di Amazon EFS
In generale, se si verificano problemi difficili da risolvere con Amazon EFS, assicurati di utilizzare un kernel Linux recente. Se si sta utilizzando una distribuzione Linux enterprise, consigliamo di attenersi alle seguenti indicazioni:
+ Amazon Linux 2 con kernel 4.3 o successivo
+ Amazon Linux 2015.09 o versioni successive
+ RHEL 7.3 o versioni successive
+ Tutte le versioni di Ubuntu 16.04
+ Ubuntu 14.04 con kernel 3.13.0-83 o versioni successive
+ SLES 12 Sp2 o versioni successive
Se si sta usando un'altra distribuzione o un kernel personalizzato, consigliamo un kernel versione 4.3 o più recente.
**Nota**
RHEL 6.9 potrebbe non essere una scelta ottimale per determinati carichi di lavoro a causa di [Prestazioni scadenti durante l'apertura di svariati file in parallelo](#open-close-operations-serialized).
**Topics**
+ [Impossibile creare un file system EFS](#cant-create-filesystem)
+ [Accesso negato ai file consentiti sul file system NFS](#nfs-16-group-limit)
+ [Errori durante l'accesso alla console Amazon EFS](#efs-console-access-errors)
+ [Blocco di istanza Amazon EC2](#ec2-instance-hangs)
+ [Blocco di un'applicazione che esegue la scrittura di grandi quantità di dati](#application-large-data-hangs)
+ [Prestazioni scadenti durante l'apertura di svariati file in parallelo](#open-close-operations-serialized)
+ [Impostazioni NFS personalizzate che causano ritardi nelle operazioni di scrittura](#custom-nfs-settings-write-delays)
+ [La creazione di backup con Oracle Recovery Manager è lenta](#oracle-backup-slow)
## Impossibile creare un file system EFS
Una richiesta di creazione di un file system EFS ha esito negativo e viene visualizzato il seguente messaggio:
```
User: arn:aws:iam::111122223333:user/username is not authorized to
perform: elasticfilesystem:CreateFileSystem on the specified resource.
```
**Operazione da eseguire**
Controlla la tua policy AWS Identity and Access Management (IAM) per confermare di essere autorizzato a creare file system EFS con le condizioni di risorse specificate. Per ulteriori informazioni, consulta [Gestione delle identità e degli accessi per Amazon EFS](security-iam.md).
## Accesso negato ai file consentiti sul file system NFS
Quando un utente a cui sono assegnati più di 16 gruppi di accesso IDs (GIDs) tenta di eseguire un'operazione su un file system NFS, gli potrebbe essere negato l'accesso ai file consentiti sul file system. [Questo problema si verifica perché il protocollo NFS ne supporta un massimo di 16 GIDs per utente e tutti gli altri GIDs vengono troncati dalla richiesta del client NFS, come definito nella RFC 5531.](https://www.rfc-editor.org/rfc/rfc5531)
**Operazione da eseguire**
Ristrutturate le mappature di utenti e gruppi NFS in modo che a ogni utente non vengano assegnati più di 16 gruppi di accesso (). GIDs
## Errori durante l'accesso alla console Amazon EFS
Questa sezione descrive gli errori che gli utenti potrebbero riscontrare durante l'accesso alla console di gestione Amazon EFS.
### Errore durante l'autenticazione delle credenziali per `ec2:DescribeVPCs`
Il seguente messaggio di errore viene visualizzato quando si accede alla console Amazon EFS:
```
AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.
```
Questo errore indica che le tue credenziali di accesso non sono state autenticate correttamente con il servizio Amazon EC2. La console Amazon EFS chiama il servizio Amazon EC2 per tuo conto durante la creazione di file system EFS nel VPC che scegli.
**Operazione da eseguire**
Assicurati che l'ora in cui il client accede alla console Amazon EFS sia impostata correttamente.
## Blocco di istanza Amazon EC2
Un'istanza Amazon EC2 può bloccarsi perché è stata eliminata una destinazione di montaggio di un file system senza prima smontare quest'ultimo.
**Operazione da eseguire**
Prima di eliminare una destinazione di montaggio di un file system, smontare il file system. Per ulteriori informazioni sullo smontaggio di un file system Amazon EFS, consulta [Smontaggio dei file system](unmounting-fs.md).
## Blocco di un'applicazione che esegue la scrittura di grandi quantità di dati
Un'applicazione che scrive una grande quantità di dati su Amazon EFS si blocca e provoca il riavvio dell'istanza.
**Operazione da eseguire**
Se un'applicazione richiede un tempo troppo lungo per scrivere tutti i suoi dati su Amazon EFS, Linux potrebbe riavviarsi perché sembra che il processo non risponda. Due parametri di configurazione del kernel definiscono questo comportamento, `kernel.hung_task_panic` e `kernel.hung_task_timeout_secs`.
Nell'esempio seguente, lo stato del processo appeso è segnalato dal comando `ps` con `D` prima del riavvio dell'istanza, indicando che il processo di attesa delle operazioni di I/O.
```
$ 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
```
Per prevenire un riavvio, aumentare il periodo di timeout o disabilitare la modalità panic del kernel al rilevamento di un'operazione in attesa. Il comando seguente disabilita la modalità panic del kernel in caso di operazione in attesa sulla maggior parte dei sistemi Linux.
```
$ sudo sysctl -w kernel.hung_task_panic=0
```
## Prestazioni scadenti durante l'apertura di svariati file in parallelo
Le applicazioni che aprono più file in parallelo non registrano l'aumento previsto delle prestazioni della I/O parallelizzazione.
**Operazione da eseguire**
Questo problema si verifica sui client Network File System versione 4 (NFSv4) e sui client RHEL 6 che utilizzano NFSv4 .1 perché questi client NFS serializzano le operazioni NFS OPEN e CLOSE. Utilizzare il protocollo NFS versione 4.1 e una delle [distribuzioni Linux](#recommend.linux.dist) consigliate che non mostrano questo problema.
Se non puoi usare NFSv4 .1, tieni presente che il client Linux NFSv4 .0 serializza le richieste di apertura e chiusura per ID utente e gruppo. IDs Questa serializzazione ha luogo anche quando più processi o più thread inviano molteplici richieste contemporaneamente. Il client invia solo un'operazione di apertura o chiusura alla volta a un server NFS, quando tutte corrispondono. IDs Per risolvere questi problemi, è possibile eseguire le seguenti azioni:
+ È possibile eseguire ogni processo da un ID utente diverso sulla stessa istanza Amazon EC2.
+ È possibile lasciare l'utente IDs lo stesso per tutte le richieste aperte e modificare IDs invece il set di gruppi.
+ È possibile eseguire ogni processo su una diversa istanza Amazon EC2.
## Impostazioni NFS personalizzate che causano ritardi nelle operazioni di scrittura
Si stanno utilizzano impostazioni del client NFS personalizzate e sono necessari fino a tre secondi affinché un'istanza Amazon EC2 veda un'operazione di scrittura eseguita su un file system da un'altra istanza Amazon EC2.
**Operazione da eseguire**
Se si verifica questo problema, è possibile risolverlo in uno dei seguenti modi:
+ Se il client NFS sull'istanza Amazon EC2 che esegue l'operazione di lettura dispone di caching degli attributi attivato, smontare il file system. Quindi rimontare utilizzando l'opzione `noac` per disabilitare il caching degli attributi. La memorizzazione nella cache degli attributi in NFSv4 .1 è abilitata per impostazione predefinita.
**Nota**
La disabilitazione della cache lato client può ridurre le prestazioni dell'applicazione.
+ È inoltre possibile deselezionare il caching degli attributi su richiesta utilizzando un linguaggio di programmazione compatibile con le procedure di NFS. Per eseguire questa operazione, è possibile inviare una richiesta alla procedura di `ACCESS` immediatamente prima di una richiesta di lettura.
Ad esempio, utilizzando il linguaggio di programmazione Python, è possibile costruire la seguente chiamata.
```
# 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)
```
## La creazione di backup con Oracle Recovery Manager è lenta
Le creazioni di backup con Oracle Recovery Manager possono essere lente se Oracle Recovery Manager si mette in sospensione per 120 secondi prima dell'avvio di un processo di backup.
**Operazione da eseguire**
Se si verifica questo problema, disabilitare Oracle Direct NFS, come descritto in [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) nell'Oracle Help Center.
**Nota**
Amazon EFS non supporta Oracle Direct NFS.
# Risoluzione dei problemi di AMI e kernel
Qui di seguito, è possibile trovare informazioni sulla risoluzione dei problemi relativi a determinate versioni di Amazon Machine Image (AMI) o del kernel quando si utilizza Amazon EFS da un'istanza Amazon EC2.
**Topics**
+ [Non è possibile eseguire il comando chown](#chown-kernal)
+ [Il file system continua a eseguire ripetutamente delle operazioni a causa di un bug del client](#file-system-stuck-client-bug)
+ [Client in deadlock](#deadlocked-client)
+ [Il recupero dell'elenco dei file di una grande cartella impiega molto tempo](#long-time-listing)
## Non è possibile eseguire il comando chown
Non è possibile modificare la proprietà di un file/directory utilizzando il `chown` comando Linux.
**Versioni di kernel che presentano questo bug**
2.6.32
**Operazione da eseguire**
È possibile evitare questo errore applicando la seguente procedura:
+ Se si sta eseguendo `chown` per la singola fase di impostazione necessaria per modificare la proprietà della directory root di EFS, è possibile eseguire il comando `chown` da un'istanza in esecuzione con un kernel più recente. Ad esempio, è possibile usare la versione più recente di Amazon Linux.
+ Se `chown` fa parte del flusso di lavoro di produzione, per utilizzare `chown` è necessario aggiornare la versione del kernel.
## Il file system continua a eseguire ripetutamente delle operazioni a causa di un bug del client
Un file system continua a eseguire ripetutamente delle operazioni a causa di un bug del client
**Operazione da eseguire**
Aggiornare il software del client alla versione più recente.
## Client in deadlock
Un client entra in stato di deadlock.
**Versioni di kernel che presentano questo bug**
+ CentOS-7 con kernel Linux 3.10.0-229.20.1.el7.x86\$164
+ Ubuntu 15.10 con kernel Linux 4.2.0-18-generic
**Operazione da eseguire**
Esegui una delle seguenti operazioni:
+ Effettuare l'upgrade a una nuova versione del kernel. In caso di CentOS-7, le versioni di kernel **Linux 3.10.0-327** o successive contengono la correzione del bug.
+ Eseguire il downgrade a una versione di kernel precedente.
## Il recupero dell'elenco dei file di una grande cartella impiega molto tempo
Ciò può verificarsi se la cartella è continuamente soggetta a modifica mentre il client NFS itera sugli elementi della cartella per terminare l'operazione di recupero dell'elenco. Quando il client NFS si accorge che i contenuti della cartella sono stati modificati durante l'iterazione, il client NFS riavvia l'iterazione dall'inizio. Di conseguenza, il comando ls può richiedere molto tempo in caso di cartella di grandi dimensioni con file modificati con una frequenza elevata.
**Versioni di kernel che presentano questo bug**
Versioni kernel CentOS e RHEL inferiori a 2.6.32-696.el6
**Operazione da eseguire**
Per risolvere il problema, effettuare l'upgrade a una nuova versione del kernel.