Duniter dev: ressources pour la synchro et espace disque

[elois]

@elois

@elois

Chez moi la db gva fait 46 Go (sync complète et terminée), donc c’est beaucoup moins que 100, mais ça reste trop. Je vais voir ce que ça change en passent à deflate pour les chunk, mais mon humble avis ça restera trop, car sled prend trop d’espaces disque, c’est censé être fortement amélioré par la v1, mais elle n’est pas encore sortie.

Avec deflate en level 3 je suis à 51Go, soit plus encore qu’avec lz4. En fait je pense que l’erreur c’est de stocker les chunk compréssés dans la db, sled semble réagir très mal à ça, autant en espace disque qu’en temps d’ouverture de la db.

Ok alors en fait le problème d’espace disque ne viens pas de sled ni de lz4 mais de mon code de création des chunks de blocks. J’ai un “current chunk” que je compresse tous les N blocs, et j’oubliais de vider ce “current chunk” à chaque cycle. Donc chaque chunk répétais le contenu de tout les précédents, ce qui donne 5.3 Go de données au lieu de 117 Mo

EDIT: et c’est aussi pour ça que trop de ressources était prises en mémoire, avec ce bug le dernier chunk contenais toute la blockchain, forcément toute la blockchain à compresser d’un bloc ça pique.
Du coup faudrait peut-être que je réessaye lz4 car il n’étais en fait pas la cause du problème.

Bon, sled prend quand même beaucoup plus d’espaces que les données qu’on y insère, mais c’est un problème connu (carrément indiqué même dans leur README), et que la v1 est censée résoudre.