-
Heap exploite un Postgres multi-pétaoctets pour l’analyse
-
Avec sa croissance rapide, le taux d’utilisation des nœuds a dépassé 80 %, provoquant des problèmes de performances dans le pipeline de collecte
-
La cause du problème est que les SSD ont tendance à voir leurs performances se dégrader lorsque leur taux d’utilisation se rapproche de 100 %
-
Le problème a été aggravé par l’utilisation de ZFS, un système de fichiers CoW (Copy-on-Write)
→ À chaque mise à jour d’un bloc, une nouvelle copie est écrite
- Bien sûr, le CoW présente plusieurs avantages
→ La compression au niveau du système de fichiers est plus simple que sur d’autres systèmes de fichiers, ce qui permet une compression de 4 à 5x et des économies d’espace
→ Sa durabilité plus élevée permet de désactiver full_page_writes de Postgres, ce qui améliore les performances et réduit les E/S globales
→ Des snapshots point-in-time qui garantissent la cohérence : comme les pages ne peuvent pas être modifiées sur place, les anciennes pages sont conservées même pendant le snapshot
- Mais les systèmes de fichiers CoW comme ZFS voient leurs performances baisser à mesure qu’ils se remplissent
→ À chaque mise à jour de page, l’allocateur de blocs doit trouver un bloc libre, donc quand le taux d’utilisation augmente, la dégradation des performances devient sévère
→ Il faut supprimer les blocs précédemment unlinkés et les réintégrer parmi les blocs existants
→ La situation a empiré parce que la taille des blocs avait été portée à 64kb pour obtenir un meilleur taux de compression
→ Pour cette raison, il vaut mieux éviter de dépasser 80 % d’utilisation avec ZFS
- Une mise à niveau vers ZFS 2.x a permis de tenter le passage de la compression lz4 à la compression Zstandard
→ lz4 est extrêmement rapide et offre un taux de compression d’environ 4,4x
→ Zstandard atteint jusqu’à ~5,5x, soit une amélioration de 20 %
→ Mais de nombreux benchmarks indiquent que Zstandard est plus lent que lz4
→ Il a donc été décidé de mener des tests rigoureux en conditions réelles
→ Résultat : les performances des requêtes n’ont pas changé, l’utilisation du stockage a baissé d’environ 20 % et le temps des requêtes d’écriture a été réduit de moitié
- Le cluster DB de Heap est réparti sur 5 nœuds, chacun appartenant à son propre ASG
→ Le remplacement d’un nœud est simple : il suffit de le détacher de l’ASG, puis l’ASG crée un nouveau nœud, restaure la dernière sauvegarde et passe en mode warm standby
→ Une AMI avec la nouvelle configuration a été créée, puis le changement a été appliqué nœud par nœud
→ Au final, l’utilisation totale a diminué d’environ 21 %, le temps d’écriture a baissé de 50 % et les performances des requêtes ont peu varié
1 commentaires
Arch Linux a remplacé l’outil de compression des paquets, passant de xz à Zstandard https://fr.news.hada.io/topic?id=1227
La renaissance des algorithmes de compression https://fr.news.hada.io/topic?id=1228
L’article ne parle pas de l’utilisation du CPU, mais dans un commentaire de l’auteur original sur HN, il indique qu’elle est passée d’environ 40 % à environ 50 %. (Autrement dit, Zstd consomme davantage de CPU.)