<p>- Heap exploite un Postgres multi-pétaoctets pour l’analyse<br />
- 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 <br />
- 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 %<br />
- Le problème a été aggravé par l’utilisation de ZFS, un système de fichiers CoW (Copy-on-Write) <br />
→ À chaque mise à jour d’un bloc, une nouvelle copie est écrite <br />
- Bien sûr, le CoW présente plusieurs avantages<br />
→ 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 <br />
→ 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 <br />
→ 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<br />
- Mais les systèmes de fichiers CoW comme ZFS voient leurs performances baisser à mesure qu’ils se remplissent<br />
→ À 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 <br />
→ Il faut supprimer les blocs précédemment unlinkés et les réintégrer parmi les blocs existants <br />
→ La situation a empiré parce que la taille des blocs avait été portée à 64kb pour obtenir un meilleur taux de compression <br />
→ Pour cette raison, il vaut mieux éviter de dépasser 80 % d’utilisation avec ZFS <br />
<br />
- Une mise à niveau vers ZFS 2.x a permis de tenter le passage de la compression lz4 à la compression Zstandard <br />
→ lz4 est extrêmement rapide et offre un taux de compression d’environ 4,4x <br />
→ Zstandard atteint jusqu’à ~5,5x, soit une amélioration de 20 % <br />
→ Mais de nombreux benchmarks indiquent que Zstandard est plus lent que lz4<br />
→ Il a donc été décidé de mener des tests rigoureux en conditions réelles <br />
→ 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é <br />
<br />
- Le cluster DB de Heap est réparti sur 5 nœuds, chacun appartenant à son propre ASG <br />
→ 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 <br />
→ Une AMI avec la nouvelle configuration a été créée, puis le changement a été appliqué nœud par nœud <br />
→ 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é </p>
1 commentaires