View a markdown version of this page

Conseils sur les performances - FSx pour Lustre

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Conseils sur les performances

Lorsque vous utilisez Amazon FSx pour Lustre, tenez compte des conseils de performances suivants. Pour connaître les limites de service, consultezQuotas de service pour Amazon FSx for Lustre.

  • I/O Taille moyenne  : Amazon FSx pour Lustre étant un système de fichiers réseau, chaque opération de fichier fait l'objet d'un aller-retour entre le client et Amazon FSx pour Lustre, ce qui entraîne une faible latence. En raison de cette latence par opération, le débit global augmente généralement à mesure que la I/O taille moyenne augmente, car les frais généraux sont amortis sur une plus grande quantité de données.

  • Modèle de demande  : en activant les écritures asynchrones dans votre système de fichiers, les opérations d'écriture en attente sont mises en mémoire tampon sur l'instance Amazon EC2 avant d'être écrites sur Amazon FSx pour Lustre de manière asynchrone. Les écritures asynchrones ont généralement des latences Moindres. Lors de l’exécution d’écritures asynchrones, le noyau utilise de la mémoire supplémentaire pour la mise en cache. Un système de fichiers qui a activé les écritures synchrones envoie des requêtes synchrones à Amazon FSx pour Lustre. Chaque opération fait l'objet d'un aller-retour entre le client et Amazon FSx for Lustre.

    Note

    Le Modèle de requête que vous avez choisi fera des compromis en termes de cohérence (si vous utilisez plusieurs instances Amazon EC2) et de vitesse.

  • Limiter la taille des répertoires  : pour obtenir des performances de métadonnées optimales sur les systèmes de fichiers Persistent 2 FSx for Lustre, limitez chaque répertoire à moins de 100 000 fichiers. La limitation du nombre de fichiers dans un répertoire réduit le temps nécessaire au système de fichiers pour verrouiller le répertoire parent.

  • Instances Amazon EC2  : les applications qui effectuent un grand nombre d'opérations de lecture et d'écriture ont probablement besoin de plus de mémoire ou de capacité informatique que les applications qui n'en effectuent pas. Lorsque vous lancez vos instances Amazon EC2 pour votre charge de travail gourmande en ressources de calcul, choisissez des types d'instances contenant la quantité de ces ressources dont votre application a besoin. Les caractéristiques de performance d'Amazon FSx pour les systèmes de fichiers Lustre ne dépendent pas de l'utilisation d'instances optimisées pour Amazon EBS.

  • Réglage recommandé de l'instance client pour des performances optimales

    1. Pour les types d'instances clients dont la mémoire est supérieure à 64 Go, nous vous recommandons d'appliquer les réglages suivants :

      sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000 sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs>
    2. Pour les types d'instances clients dotés de plus de 64 cœurs de processeur virtuel, nous vous recommandons d'appliquer les réglages suivants :

      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

      Une fois le client monté, les réglages suivants doivent être appliqués :

      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. Pour optimiser les performances de la liste des répertoires (ls), les réglages suivants doivent être appliqués :

      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

    Notez qu'il lctl set_param est connu pour ne pas persister après le redémarrage. Comme ces paramètres ne peuvent pas être définis de façon permanente côté client, il est recommandé d'implémenter une tâche cron de démarrage pour définir la configuration avec les réglages recommandés.

  • Équilibre de la charge de travail entre les différents systèmes d'exploitation  : dans certains cas, votre charge de travail ne détermine pas le débit global que votre système de fichiers peut fournir (200 Mbit/s par TiB de stockage). Si tel est le cas, vous pouvez utiliser CloudWatch des métriques pour déterminer si les performances sont affectées par un déséquilibre dans les I/O modèles de votre charge de travail. Pour déterminer si cela en est la cause, consultez la CloudWatch métrique Maximum pour Amazon FSx for Lustre.

    Dans certains cas, cette statistique indique une charge égale ou supérieure à 240 Mbit/s de débit (la capacité de débit d'un seul disque Amazon FSx for Lustre de 1,2 TiB). Dans ce cas, votre charge de travail n'est pas répartie de manière uniforme sur vos disques. Si tel est le cas, vous pouvez utiliser la lfs setstripe commande pour modifier le découpage des fichiers auxquels votre charge de travail accède le plus fréquemment. Pour des performances optimales, répartissez les fichiers présentant des exigences de débit élevées sur tous les systèmes d'exploitation de votre système de fichiers.

    Si vos fichiers sont importés depuis un référentiel de données, vous pouvez adopter une autre approche pour répartir uniformément vos fichiers haut débit sur vos OST. Pour ce faire, vous pouvez modifier le ImportedFileChunkSize paramètre lors de la création de votre prochain système de fichiers Amazon FSx for Lustre.

    Supposons, par exemple, que votre charge de travail utilise un système de fichiers de 7 Tio (composé de 6 OST de 1,17 TiB) et qu'elle doive générer un débit élevé sur des fichiers de 2,4 Go. Dans ce cas, vous pouvez définir la ImportedFileChunkSize valeur pour (2.4 GiB / 6 OSTs) = 400 MiB que vos fichiers soient répartis uniformément sur les OST de votre système de fichiers.

  • Lustreclient pour les IOPS de métadonnées  : si une configuration de métadonnées est spécifiée pour votre système de fichiers, nous vous recommandons d'installer un client Lustre 2.15 ou Lustre 2.12 avec l'une des versions de système d'exploitation suivantes : Amazon Linux 2023 ; Amazon Linux 2 ; Red Hat/Rocky Linux 8.9, 8.10 ou 9.x ; CentOS 8.9 ou 8.10 ; Ubuntu 22+ avec un noyau 6.2, 6.5 ou 6.8 ; ou Ubuntu 20.

Intelligent-Tiering considérations relatives aux performances

Voici quelques points importants à prendre en compte en matière de performances lorsque vous travaillez avec des systèmes de fichiers utilisant la classe Intelligent-Tiering de stockage :

  • Les charges de travail lisant des données de plus petite I/O taille nécessiteront une plus grande simultanéité et entraîneront des coûts de demande plus élevés pour atteindre le même débit que les charges de travail utilisant des I/O tailles plus importantes en raison de la latence plus élevée des niveaux de stockage. Intelligent-Tiering Nous vous recommandons de configurer le cache de lecture de votre SSD suffisamment grand pour prendre en charge une simultanéité et un débit plus élevés lorsque vous travaillez avec des tailles d'E/S plus petites.

  • Le nombre maximal d'IOPS sur disque que vos clients peuvent effectuer avec un système de Intelligent-Tiering fichiers dépend des modèles d'accès spécifiques de votre charge de travail et de la mise en place d'un cache de lecture SSD. Pour les charges de travail à accès aléatoire, les clients peuvent généralement générer des IOPS beaucoup plus élevées si les données sont mises en cache dans le cache de lecture du SSD que si elles ne se trouvent pas dans le cache.

  • Intelligent-Tiering La classe de stockage prend en charge la lecture anticipée pour optimiser les performances des demandes de lecture séquentielles. Nous vous recommandons de configurer votre modèle d'accès aux données de manière séquentielle dans la mesure du possible afin de permettre la pré-extraction des données et d'améliorer les performances.