Journal Recette de cuisine : base whisper (carbon, graphite) avec zram et anything-sync-daemon

Posté par  . Licence CC By‑SA.
13
26
fév.
2018

Dur de faire un titre là. Euh, bref, j'ai la configuration suivante :

  • collectd pour faire de la collecte de métriques.
  • go-carbon (implémentation en go de carbon-cache) qui stockent ces métriques.
  • Un SSD en dessous.

Le problème, c'est que j'ai ce SSD depuis environ 155 jours, et qu'il a déjà comptabilisé 5,43 Tio en écriture. C'est un peu beaucoup, pour un SSD de 256 Go.

Une solution serait de collecter moins de données : collectd ramasse des tas de trucs, toutes les 10 secondes, ça fait un paquet de données, dont la plupart ne me servent à rien. Jusque là. Et puis ce ne serait pas drôle.

J'ai donc opté pour la solution suivante :

  • zram Pour utiliser de la RAM, mais avec compression.
  • anything-sync-daemon Qui permet d'utiliser un point de montage RAM en lecture-écriture au lieu du disque, avec resynchronisation périodique sur le disque.

Configuration de zram

En bloc :

modprobe zram
echo 'lz4' > comp_algorithm
echo '2G' > disksize
/sbin/mkfs.ext4 -O '^has_journal' -L zram_disk /dev/zram0
mkdir /tmp/compressed_ram/
mount /dev/zram0 /tmp/compressed_ram/

En détails :

  • Chargement du module, avec la création d'un périphérique par défaut (/dev/zram0)
  • Paramétrage de l'algorithme de compression. lz4 est très rapide. J'ai fini par choisir deflate, parce que j'ai eu les résultats suivants sur un jeu d'environ 700 Mio de données.
Algorithme Ratio (compressé/brut)
lz4 39,86%
lz4hc 34,66%
lzo 38,16%
deflate 23,92%
  • Paramétrage de la taille du disque. Cela correspond à la taille des données qui seront dedans, pas la taille de la RAM utilisée.
  • Création du système de fichiers. Et oui, c'est un périphérique brut, il faut l'initialiser. Si vous avez des astuces pour les options, je suis preneur.
  • Création du point de montage, et montage.

Bien sûr, tout ça est à refaire à chaque démarrage de la machine, vu que c'est volatil. Je ne me suis pas encore attelé à cette tâche.

Configuration de anything-sync-daemon

Édition de /etc/asd.conf:

WHATTOSYNC=('/var/lib/graphite/whisper/server/metric1' '/var/lib/graphite/whisper/server/metric2' '/var/lib/graphite/whisper/server/metric3')
VOLATILE="/tmp/compressed_ram"
USE_OVERLAYFS="no"
USE_BACKUPS="no"
  • Je n'ai pas mis toutes les métriques : je n'ai pas assez de RAM pour ça
  • Les sauvegardes, c'est pour les faibles je n'en ai pas besoin dans mon cas, ce sont des métriques que je peux me permettre de perdre. Au pire, j'ai des sauvegardes quotidiennes.
  • Overlay, c'est bien, ça permet de n'écrire en RAM que les données qui ont changé. À l'usage, pour Graphite, les fichiers changent tous et tout le temps. C'est vraiment pas très utile, sauf si vous avez synchronisé des métriques obsolètes.

Vérification et lancement

asd p
systemctl start asd

La première commande vous fait un petit résumé. La deuxième invoque Belzébuth lance le service, qui s'occupe de trifouiller vos points de montage, et de resynchroniser les données une fois par heure sur le disque.

Ça ne marche pas

Oui, c'est vrai. Voir : https://github.com/graysky2/anything-sync-daemon/pull/54
Anything-sync-daemon filtre les périphériques qui ne sont pas de la RAM, et il ne connaît pas (encore) zram.

Conclusion

Je suis passé d'un taux d'écriture d'environ 75 Mio/s à 35 Mio/s en délocalisant seulement 1,4 Gio de métriques sur les 9,6 Gio (certaines sont quand même non utilisées). Je n'ai pas mesuré l'activité quand la collecte est désactivée, mais c'est déjà beaucoup plus raisonnable.

  • # Tag invalide

    Posté par  . Évalué à 2. Dernière modification le 26/02/18 à 14:05.

    EDIT: Ah ben en fait, j'ai pu éditer les tags moi-même.

    Bon, la syntaxe change d'un système à l'autre, désolé. C'était plutôt :

    collectd carbon graphite anything-sync-daemon zram

    Merci au modérateur l'enlever le premier tag, complètement inutile.

  • # De la robustesse des SSD

    Posté par  . Évalué à 5.

    Le problème, c'est que j'ai ce SSD depuis environ 155 jours, et qu'il a déjà comptabilisé 5,43 Tio en écriture. C'est un peu beaucoup, pour un SSD de 256 Go.

    C'est vraiment beaucoup ça? À ce rythme, cela corresponds à 12-13 To par an, soit une cinquantaine de cycles d'écriture par an pour 256Go. Un SSD c'est combien de cycle d'écriture maintenant? Même avec 2000 cycles, tu en as pour 40 ans d'utilisation à ce rythme…

  • # Cache

    Posté par  . Évalué à 1.

    Ce que tu met en place me semble être un système de cache. Une solution ne pourrait pas être d'utiliser une partition spécifique et de paramétrer le iosched de ce dernier ?

    • [^] # Re: Cache

      Posté par  . Évalué à 3.

      C'est ça, c'est un cache. Un cache qui n'écrit que toutes les heures.

      Alors, je pourrais faire une partition dédiée, mais il me faudrait réduire l'existante, m'assurer qu'il y aura assez de place sur la nouvelle, c'est du boulot et ça manque de dynamisme.

      Mais disons que c'est une solution : je serais très curieux de voir les paramètres d'un ordonnanceur qui fait la même chose. Allez, sans la compression.

      • [^] # Re: Cache

        Posté par  (site Web personnel) . Évalué à 3.

        Mais du coup en cas de crash, tu perds 1h de collecte. Considérant les commentaires précédents sur la durée de vie du SSD, c'est un risque qui semble assez peu justifié, surtout si on tient compte de la complexité additionnelle. Après, c'est amusant et intéressant je te l'accorde !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.