View a markdown version of this page

Suggerimenti per le prestazioni - FSx per Lustre

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à.

Suggerimenti per le prestazioni

Quando usi Amazon FSx for Lustre, tieni a mente i seguenti suggerimenti sulle prestazioni. Per i limiti di servizio, consulta. Quote di servizio per Amazon FSx for Lustre

  • I/O Dimensioni medie: poiché Amazon FSx for Lustre è un file system di rete, ogni operazione relativa ai file viene eseguita tra il client e Amazon FSx for Lustre, con un leggero sovraccarico di latenza. A causa di questa latenza per operazione, il throughput complessivo generalmente aumenta all'aumentare della I/O dimensione media, poiché l'overhead viene ammortizzato su una maggiore quantità di dati.

  • Modello di richiesta: abilitando le scritture asincrone sul file system, le operazioni di scrittura in sospeso vengono memorizzate nel buffer sull'istanza Amazon EC2 prima di essere scritte in Amazon FSx for Lustre 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 invia richieste sincrone ad Amazon FSx for Lustre. Ogni operazione viene eseguita tra il client e Amazon FSx for Lustre.

    Nota

    La modalità di richiesta presenta compromessi in termini di consistenza (se si utilizzano molteplici istanze Amazon EC2) e di velocità.

  • Limita le dimensioni delle directory: per ottenere prestazioni ottimali dei metadati sui file system Persistent 2 FSx for Lustre, limita ogni directory a meno di 100.000 file. La limitazione del numero di file in una directory riduce il tempo necessario al file system per acquisire un blocco sulla directory principale.

  • Istanze Amazon EC2: le applicazioni che eseguono un numero elevato di operazioni di lettura e scrittura richiedono probabilmente più memoria o capacità di calcolo rispetto alle applicazioni che non lo fanno. Quando avvii le istanze Amazon EC2 per il tuo carico di lavoro ad alta intensità di calcolo, scegli i tipi di istanze con la quantità di queste risorse necessaria alla tua applicazione. Le caratteristiche prestazionali dei file system Amazon FSx for Lustre non dipendono dall'uso di istanze ottimizzate per Amazon EBS.

  • Ottimizzazione consigliata delle istanze del client per prestazioni ottimali

    1. Per i tipi di istanze client con memoria superiore a 64 GiB, consigliamo di applicare la seguente ottimizzazione:

      sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000 sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs>
    2. Per i tipi di istanze client con più di 64 core vCPU, consigliamo di applicare la seguente ottimizzazione:

      echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf # reload all kernel modules to apply the above two settings sudo reboot

      Dopo aver montato il client, è necessario applicare la seguente ottimizzazione:

      sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32 sudo lctl set_param mdc.*.max_rpcs_in_flight=64 sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50
    3. Per ottimizzare le prestazioni per l'elenco delle directory (ls), è necessario applicare la seguente ottimizzazione:

      sudo lctl set_param llite.*.statahead_max=512 sudo lctl set_param llite.*.statahead_agl=1 if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then sudo lctl set_param llite.*.statahead_xattr=1 else echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning" fi

    Nota che lctl set_param è noto che non persiste dopo il riavvio. Poiché questi parametri non possono essere impostati in modo permanente dal lato client, si consiglia di implementare un cron job di avvio per impostare la configurazione con le regolazioni consigliate.

  • Bilanciamento del carico di lavoro tra gli OST: in alcuni casi, il carico di lavoro non determina il throughput aggregato che il file system è in grado di fornire (200 MBps per TiB di storage). In tal caso, puoi utilizzare le CloudWatch metriche per risolvere se le prestazioni sono influenzate da uno squilibrio nei modelli del carico di lavoro. I/O Per identificare se questa è la causa, consulta la CloudWatch metrica massima per Amazon FSx for Lustre.

    In alcuni casi, questa statistica mostra un carico pari o superiore a 240 MBps di throughput (la capacità di throughput di un singolo disco Amazon FSx for Lustre da 1,2 TiB). In questi casi, il carico di lavoro non è distribuito uniformemente tra i dischi. In tal caso, puoi utilizzare il lfs setstripe comando per modificare lo striping dei file a cui il carico di lavoro accede più frequentemente. Per prestazioni ottimali, esegui lo striping dei file con requisiti di throughput elevati in tutti gli OST che compongono il file system.

    Se i tuoi file vengono importati da un archivio di dati, puoi adottare un altro approccio per suddividere i file ad alta velocità in modo uniforme tra i tuoi OST. A tale scopo, puoi modificare il ImportedFileChunkSize parametro durante la creazione del tuo prossimo file system Amazon FSx for Lustre.

    Ad esempio, supponiamo che il carico di lavoro utilizzi un file system da 7,0 TiB (composto da 6 OST da 1,17 TiB) e debba generare un throughput elevato su file da 2,4 GiB. In questo caso, puoi impostare il ImportedFileChunkSize valore su in modo che i tuoi file siano distribuiti in modo uniforme tra gli OST del tuo file system. (2.4 GiB / 6 OSTs) = 400 MiB

  • Lustreclient per metadati IOPS — Se il tuo file system ha una configurazione di metadati specificata, ti consigliamo di installare un client Lustre Lustre 2.15 o un client 2.12 con una delle seguenti versioni del sistema operativo: Amazon Linux 2023; Amazon Hat/Rocky Linux 2; Red Linux 8.9, 8.10 o 9.x; CentOS 8.9 o 8.10; Ubuntu 22+ con kernel 6.2, 6.5 o 6.8; o Ubuntu 20.

Intelligent-Tiering considerazioni sulle prestazioni

Ecco alcune importanti considerazioni sulle prestazioni quando si lavora con file system che utilizzano la classe Intelligent-Tiering di storage:

  • I carichi di lavoro che leggono dati di I/O dimensioni inferiori richiederanno una maggiore concorrenza e comporteranno maggiori costi di richiesta per ottenere lo stesso throughput dei carichi di lavoro che utilizzano grandi I/O dimensioni a causa della maggiore latenza tra i livelli di storage. Intelligent-Tiering Consigliamo di configurare una cache di lettura SSD sufficientemente grande da supportare una maggiore concorrenza e velocità effettiva quando si lavora con I/O di dimensioni inferiori.

  • Il numero massimo di IOPS su disco che i tuoi clienti possono generare con un Intelligent-Tiering file system dipende dai modelli di accesso specifici del carico di lavoro e dal fatto che tu abbia fornito o meno una cache di lettura SSD. Per i carichi di lavoro con accesso casuale, i client possono in genere generare IOPS molto più elevati se i dati sono memorizzati nella cache di lettura dell'SSD rispetto a quando i dati non sono nella cache.

  • Intelligent-Tiering la classe di storage supporta la lettura anticipata per ottimizzare le prestazioni per le richieste di lettura sequenziali. Ti consigliamo di configurare il modello di accesso ai dati in sequenza, quando possibile, per consentire il prerecupero dei dati e prestazioni più elevate.