Méthode de tuning ZFS adaptée aux charges de travail à accès aléatoire (Random access)

• Les paramètres par défaut de ZFS sont définis comme un compromis entre accès séquentiel et accès aléatoire
  • Si l’on connaît clairement les caractéristiques de la charge de travail, un tuning plus agressif est possible
• Explication de la différence entre accès séquentiel et accès aléatoire
  • Sur HDD, à cause du déplacement des têtes, les performances en accès aléatoire peuvent être des dizaines à des centaines de fois plus lentes que celles en accès séquentiel
  • Même sur SSD, l’accès aléatoire s’est nettement amélioré, mais l’accès séquentiel reste plus efficace
  • Une charge qui lit de gros fichiers dans l’ordre a une forte tendance à l’accès séquentiel
  • Une charge qui lit fréquemment de nombreux petits fichiers a facilement une forte tendance à l’accès aléatoire
• Présentation des méthodes d’analyse de la charge de travail
  • Raisonnement logique basé sur le code ou la structure
  • Calcul de la taille moyenne des E/S à partir du débit (bps) + du nombre d’E/S par seconde (iops)
  • Analyse de la distribution des tailles d’E/S via zpool iostat -r
• Interprétation de zpool iostat -r
  • ind : taille de chaque requête logique individuelle
  • agg : taille des E/S réellement fusionnées et exécutées
  • Si agg est supérieur à ind, cela signifie que la fusion des E/S adjacentes fonctionne bien
• Résultats de l’analyse d’une charge de travail exemple
  • Environ 76 % de lectures synchrones
  • Plus de 99 % des lectures sont de 32 KiB ou moins
  • Les écritures asynchrones ont elles aussi une forte proportion de petites E/S
  • Globalement, il s’agit d’une charge avec une très forte tendance à l’accès aléatoire
• zfs_prefetch_disable
  • ZFS précharge dans l’ARC les blocs adjacents lorsqu’il détecte un schéma d’accès séquentiel
  • Sur une charge à accès aléatoire, le taux de succès du prefetch peut être faible et n’augmenter que les E/S inutiles
  • Il est possible de mesurer l’efficacité du prefetch à partir de arc_summary
  • Si le taux de succès est faible, on peut envisager zfs_prefetch_disable
• recordsize
  • La valeur par défaut est 128K
  • Dans la charge d’exemple, la majorité des E/S étant de 32 KiB ou moins, on peut envisager un recordsize plus petit
• Choix de la valeur optimale
  • Il est important de la déterminer sur la base de benchmarks
  • Pour des bases de données comme MySQL/Postgres, il existe déjà de nombreux cas de tuning validés
  • En général, on utilise souvent un recordsize proche de la taille des pages de la base de données