Optimiser les performances des disques persistants

Optimiser les disques persistants

Les disques persistants vous offrent les performances décrites dans le tableau de comparaison des différents types de disques si la VM utilise suffisamment de ressources pour atteindre les plafonds de performances. Une fois que vous avez dimensionné les volumes de vos disques persistants en fonction des performances attendues, votre application et votre système d'exploitation peuvent nécessiter des ajustements.

Les sections suivantes décrivent quelques éléments clés qui peuvent être ajustés pour offrir de meilleures performances, et expliquent comment appliquer certains d'entre eux à des types de charges de travail spécifiques.

Limiter les charges d'E/S importantes à 50 To

Remarque : Les charges d'E/S importantes atteignent des performances maximales lorsqu'elles sont limitées à 50 To. Les plages de différents disques persistants qui totalisent jusqu'à 50 To peuvent être considérées comme égales à une seule plage de 50 To à des fins de performances. Une plage fait référence à une plage contiguë d'adresses de blocs logiques sur un seul disque physique.

Désactiver l'initialisation différée et activer les commandes DISCARD

Les disques persistants sont compatibles avec les commandes DISCARD ou TRIM, qui permettent aux systèmes d'exploitation d'informer les disques lorsque les blocs ne sont plus utilisés. Cette compatibilité avec DISCARD permet au système d'exploitation de marquer des blocs de disque comme n'étant plus nécessaires, sans encourir le coût de leur mise à zéro.

Sur la plupart des systèmes d'exploitation Linux, vous activez DISCARD dès lors que vous installez un disque persistant sur votre instance. De même, les instances Windows Server 2012 R2 activent DISCARD par défaut lorsque vous installez un disque persistant. Windows Server 2008 R2, en revanche, n'est pas compatible avec DISCARD.

L'activation de DISCARD peut améliorer les performances d'exécution générales et peut également accélérer les performances de votre disque lors de sa première installation. Formater le volume entier d'un disque peut prendre du temps. Ainsi, il est courant de faire appel aux fameuses commandes "Lazy". L'inconvénient de cette pratique, c'est qu'on la paye souvent la première fois que le volume est installé. En désactivant l'initialisation différée et en activant les commandes DISCARD, vous pouvez augmenter la rapidité de vos formatages et installations.

  • Désactivez l'initialisation différée et activez DISCARD lors du formatage en transmettant les paramètres suivants à mkfs.ext4 :

    -E lazy_itable_init=0,lazy_journal_init=0,discard
    

    Le paramètre lazy_journal_init=0 ne fonctionne pas sur les instances avec des images CentOS 6 ou RHEL 6. Pour ces instances, formatez les disques persistants sans ce paramètre.

    -E lazy_itable_init=0,discard
    
  • Activez les commandes DISCARD lors de l'installation, et transmettez l'indicateur suivant à la commande d'installation :

    -o discard
    

Les disques persistants présentent un fonctionnement optimal lorsque l'option discard est activée. Cependant, vous pouvez exécuter périodiquement fstrim en plus de l'option discard, ou en lieu et place de celle-ci. Si vous n'utilisez pas l'option discard, exécutez fstrim avant de créer un instantané de votre disque. L'ajustement du système de fichiers vous permet de créer des instantanés plus petits, ce qui réduit leur coût de stockage.

Profondeur de la file d'attente d'E/S

De nombreuses applications disposent de paramètres qui jouent sur la profondeur de la file d'attente d'E/S. La définition d'une profondeur plus importante augmente les IOPS, mais risque également d'accroître la latence. À l'inverse, une profondeur moindre réduit la latence par E/S, mais cela s'effectue parfois au détriment des IOPS.

Cache Readahead

Pour améliorer les performances d'E/S, les systèmes d'exploitation utilisent des techniques telles que readahead, qui consiste à lire une plus grande partie du fichier que nécessaire, en se basant sur l'idée que les lectures ultérieures sont susceptibles d'avoir besoin de ces données. Un cache readahead supérieur augmente le débit, mais au détriment de la mémoire et des IOPS. Un cache readahead plus faible augmente les IOPS, mais au détriment du débit.

Sur les systèmes Linux, vous pouvez obtenir et définir la valeur readahead avec la commande blockdev :

$ sudo blockdev --getra /dev/[DEVICE_ID]
$ sudo blockdev --setra [VALUE] /dev/[DEVICE_ID]

La valeur de readahead est égale à : <desired_readahead_bytes> / 512 octets.

Imaginons que vous désirez définir un readahead de 8 Mo. 8 Mo correspondent à 8 388 608 octets (8 * 1 024 * 1 024).

8388608 bytes / 512 bytes = 16384

Définissez la commande blockdev sur 16384 :

$ sudo blockdev --setra 16384 /dev/[DEVICE_ID]

Processeurs disponibles

La lecture et l'écriture sur disque persistant consomment des cycles de processeur de votre VM. Pour atteindre des niveaux fiables et élevés d'IOPS, il est nécessaire de disposer de processeurs disponibles pour traiter les E/S.

Charges de travail axées IOPS

Les bases de données, qu'elles soient de type SQL ou NoSQL, présentent des modèles d'accès aux données aléatoires. Google recommande les valeurs suivantes pour les charges de travail axées IOPS :

  • Définissez les valeurs de profondeur de file d'attente d'E/S sur 1 pour 400 à 800 IOPS, sans dépasser 64 sur les volumes importants.

  • Prévoyez un processeur disponible tous les 2 000 IOPS en lecture aléatoire et un processeur disponible tous les 2 500 IOPS en écriture aléatoire.

Abaissez le cache readahead aux valeurs généralement suggérées dans les bonnes pratiques pour MongoDB, Apache Cassandra et les autres applications de base de données.

Charges de travail orientées débit

Les opérations de streaming, telles qu'une tâche Hadoop, bénéficient de lectures séquentielles rapides. De ce fait, des tailles d'E/S plus importantes peuvent augmenter les performances de diffusion. Pour les charges de travail orientées débit, des valeurs d'E/S de 256 Ko ou plus sont recommandées.

Optimiser les performances des disques persistants standards

Pour obtenir des niveaux de débit maximum de manière cohérente pour les disques persistants standards, appliquez les bonnes pratiques suivantes :

  • Si possible, utiliser des flux d'E/S séquentiels parallèles

    Utilisez des E/S séquentielles sur les disques persistants standard, car le système est conçu pour optimiser les performances des E/S pour un accès séquentiel au disque, comme pour un disque dur HDD réel.

    La distribution des E/S sur plusieurs flux séquentiels permet d'améliorer considérablement les performances, le meilleur niveau de cohérence étant obtenu avec au moins huit flux séquentiels.

  • Utiliser des E/S de grande taille

    Les disques persistants standards offrent un débit très élevé à la limite. Pour garantir que les limites et la latence des IOPS ne créeront pas de goulot d'étranglement pour les performances de votre application, utilisez une taille d'E/S d'au moins 256 Ko ou supérieure.

    Utilisez des tailles de bande élevées pour les applications de système de fichiers distribué. Une charge d'E/S aléatoire utilisant des tailles de bandes élevées (par exemple, supérieures à 4 Mo) permet d'obtenir des performances élevées sur les disques persistants standards. Cela est dû au fait que la charge imite presque parfaitement l'accès au disque par plusieurs flux séquentiels.

  • Veiller à fournir des E/S avec suffisamment de parallélisme

    Utilisez une profondeur de file d'attente aussi élevée que possible, de manière à tirer parti du parallélisme du système d'exploitation. L'utilisation d'une profondeur de file d'attente suffisamment élevée est particulièrement importante pour les disques persistants standards afin d'atteindre le débit à la limite sans que la latence des E/S ne crée de goulot d'étranglement dans votre application.

Optimiser les performances des disques persistants SSD

Le tableau des performances par type de disque décrit les performances maximales attendues et réalisables pour les disques persistants SSD. Pour optimiser vos applications et instances de VM afin d'atteindre ces vitesses, conformez-vous aux bonnes pratiques suivantes :

  • Assurez-vous que votre application génère suffisamment d'E/S

    Si votre application génère moins d'IOPS que la limite décrite dans le tableau ci-dessus, vous n'atteindrez pas ce niveau d'IOPS. Par exemple, sur un disque de 500 Go, la limite attendue s'élève à 15 000 IOPS. Toutefois, si vous en générez moins ou si vous émettez des opérations d'E/S supérieures à 8 Ko, vous n'atteindrez pas 15 000 IOPS.

  • Veiller à fournir des E/S avec suffisamment de parallélisme

    Utilisez une profondeur de file d'attente suffisamment élevée pour tirer parti du parallélisme du système d'exploitation. Si vous émettez 1­  ­000 IOPS de manière synchrone et avec une profondeur de file d'attente de 1, vous obtiendrez beaucoup moins d'IOPS que la limite décrite dans le tableau. Votre application doit présenter au minimum une profondeur de file d'attente de 1 pour 400 à 800 IOPS.

  • Assurez-vous d'avoir suffisamment de processeurs disponibles sur l'instance émettant les E/S

    Si votre instance de VM manque de ressources de processeur, votre application ne pourra pas gérer les taux d'IOPS décrits ci-dessus. Nous vous recommandons d'avoir un processeur disponible pour 2 000 à 2 500 IOPS de trafic attendu.

  • Assurez-vous que votre application est optimisée pour offrir une localité temporelle des données raisonnable sur les disques de grande capacité

    Si votre application accède à des données réparties sur différentes parties d'un disque sur une courte période (à raison de plusieurs centaines de Go par processeur virtuel), vous n'atteindrez pas les valeurs IOPS optimales. Pour des performances maximales, optimisez la localité temporelle des données et des facteurs de pondération tels que la fragmentation du disque et le caractère aléatoire des parties du disque consultées.

  • Assurez-vous que le programmeur d'E/S du système d'exploitation est configuré pour répondre à vos besoins spécifiques

    Sur les systèmes Linux, vous pouvez paramétrer le programmeur d'E/S sur noop pour obtenir le plus grand nombre d'IOPS sur les périphériques exploitant un disque SSD.

Effectuer l'analyse comparative des performances d'un disque persistant SSD

Les commandes ci-dessous prennent l'exemple d'un disque persistant SSD de 2 500 Go. Si la taille de votre disque est différente, modifiez la valeur de l'argument --filesize. Cette taille de disque est nécessaire pour atteindre les limites de débit de 32 processeurs virtuels par VM.

    # Install dependencies
    sudo apt-get update
    sudo apt-get install -y fio
  1. Remplissez le disque avec des données non nulles. Les lectures à partir de blocs vides ont un profil de latence différent des lectures de blocs contenant des données. Nous vous recommandons donc de remplir le disque avant de lancer des analyses comparatives de latence de lecture.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=fill_disk \
      --filename=/dev/sdb --filesize=2500G \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=128K --iodepth=64 --rw=randwrite
    
  2. Testez la bande passante en écriture à l'aide d'écritures séquentielles comportant plusieurs flux parallèles (plus de 8). Prévoyez une taille d'E/S de 1 Mo et une profondeur d'E/S égale ou supérieure à 64.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=write --numjobs=8 --offset_increment=100G
    
  3. Testez les IOPS en écriture. Pour atteindre le nombre maximal d'IOPS des disques persistants, vous devez conserver une file d'attente d'E/S de grande profondeur. Par exemple, si la latence d'écriture est de 1 milliseconde, la VM peut atteindre au maximum 1 000 IOPS pour chaque E/S en cours de transfert. Pour atteindre 15 000 IOPS, la VM doit maintenir au moins 15 E/S. Si votre disque et votre VM peuvent atteindre 30 000 IOPS, le nombre d'E/S en cours de transfert doit être d'au moins 30 E/S. Si la taille des E/S est supérieure à 4 Ko, il est possible que la VM atteigne la limite de bande passante avant d'atteindre la limite d'IOPS.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randwrite
    
  4. Testez la latence en écriture. Lors du test de la latence par E/S, la VM ne doit pas atteindre la limite de bande passante ou d'IOPS, sinon la latence observée ne reflétera pas la latence réelle des E/S du disque persistant. Par exemple, si la limite d'IOPS est atteinte avec une profondeur d'E/S de 30 et que la commande fio présente le double de cette valeur, alors le total d'IOPS reste le même et la latence d'E/S rapportée double.

    # Running this command causes data loss on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randwrite
    
  5. Testez la bande passante en lecture à l'aide de lectures séquentielles comportant plusieurs flux parallèles (plus de 8). Prévoyez une taille d'E/S de 1 Mo et une profondeur d'E/S égale ou supérieure à 64.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=read --numjobs=8 --offset_increment=100G
    
  6. Testez les IOPS en lecture. Pour atteindre le nombre maximal d'IOPS des disques persistants, vous devez conserver une file d'attente d'E/S de grande profondeur. Si la taille des E/S est supérieure à 4 Ko, il est possible que la VM atteigne la limite de bande passante avant d'atteindre la limite d'IOPS.

    sudo fio --name=read_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randread
    
  7. Testez la latence en lecture. Il est important de remplir le disque avec des données afin d'obtenir une mesure de latence réaliste. Il est important que la VM n'atteigne pas les limites d'IOPS ou de débit lors de ce test : une fois que le disque persistant atteint sa limite de saturation, il repousse toute E/S, ce qui se traduit par une augmentation artificielle de la latence des E/S.

    sudo fio --name=read_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randread
    
  8. Testez la bande passante en lecture séquentielle.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=read
    
  9. Testez la bande passante en écriture séquentielle.

    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=write
    

Étape suivante

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine