Duniter dev: ressources pour la synchro et espace disque

J’ai pris le risque de voir ce que ça donnait. Et ça ne peut pas aller au bout sur mon serveur. Ça prend trop de ressources. J’ai l’impression qu’il n’est pas plus coûteux de refaire une synchro complète.

dex migrate est beaucoup plus rapide qu’une resynchro complète.

De quel type de ressource parle tu : mémoire ? cpu ? les deux ?

Je pense que c’est plutôt un changement récent de ma part qui fait exploser le cpu en sync, car désormais je compresse des chunk de bloc au fur et à mesure pour pouvoir les fournir directement dans la future sync par GVA, le but est de réduire la quantité de données qu’on a besoin de transiter sur le réseau pour une sync, en demandant les calculs de compression/décompression au noeud qui veut ce sync et pas aux noeuds requêtés afin qu’un attaquant ne puisse pas surcharger les noeuds.

Ce que je veux dire c’est que c’est peut-être pas lié à dex migrate, tu aurais alors le même souci en sync «classique».

Mémoire je pense. Ça a fini par un « kiiled », deux fois de suite. Je n’ai pas beaucoup de RAM : 4Go, partagés avec d’autres services. Donc je bride l’instance duniter à 2,5Go.

Ça semble malheureusement se confirmer. La synchro qui n’était déjà pas très rapide est significativement plus lente.

Ok merci du retour, faut que j’investigue pour voir comment améliorer ça, peut être déjà essayer d’autre algo de compression, là j’étais parti sur lz4, car c’est le plus rapide connu (mais avec un taux de compression moyen).

1 J'aime

C’est bien ça :

May 17 20:24:30 serveur kernel: node invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0
1 J'aime

Il y a encore quelques jours je pouvais faire une synchro en limitant la RAM de mon instance à 2Go. Aujourd’hui même avec 4Go ça ne passe pas les 28% d’avancement.

Ça veut dire que les raspberry pi dotés de 4Go ou moins ne pourront plus servir de noeud. C’est un peu dommage, je trouve.

Je ne suis pas certain que la bande passante nécessaire pour une synchro était si problématique. Sur mon serveur de base j’avais réussi à synchroniser en 90minutes (mon record sur cette machine) avec mon dernier patch. Ça semble parfaitement acceptable. Surcharger la RAM et la CPU pour gagner à peine quelques minutes sur des machines de course n’est peut-être pas une bonne idée.

Ben non qui à dit qu’on allait rester comme ça ? J’essaye un truc, je vois que ça bouffe beaucoup de ressources, je réadapte :wink:

D’une part ce serait beaucoup plus que quelques minutes, d’autres part ça réduit aussi considérablement l’espace de stockage occupé par les chunk, donc ça réduit la taille de la db.
Je compte garder la compression, faut juste changer l’algo de compression, c’est lz4 qui bouffe beaucoup trop de RAM.

1 J'aime

J’ai fait quelques tests complémentaires, et en particulier un test de synchro depuis mon PC perso (16 Go de RAM), juste après reboot afin d’éviter les effets de bord. Ça se termine là :

2021-05-18T07:45:58+00:00 - info: GOT chunck #1368/3028 from 342000 to 342249 on peer gtest.jytou.fr

Avec la mémoire complètement saturée :

mai 18 09:46:01 pinibrem15 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=docker-7fb9c3662c6f809030b63b6e74106ea6a6165456ef0ad61faa31fdc0f3c6d6eb.scope,mems_allowed=0,global_oom,task_memcg=/>
mai 18 09:46:01 pinibrem15 kernel: Out of memory: Killed process 3819 (node) total-vm:17543136kB, anon-rss:14934656kB, file-rss:0kB, shmem-rss:0kB, UID:1111 pgtables:41700kB oom_score_adj:0

À noter également l’empreinte stockage qui augmente de deux ordres de grandeur :

  • Avant, l’espace disque était < 2Go à la fin de la synchro
  • Lors de ce test interrompu vers 45%, on est monté à 23 Go. L’augmentation semble croître proportionnellement au cours de l’avancement, au point que j’anticipe dans les 100Go au total.

Tout cet espace est occupé par gva_v1_sled.

Hope this helps…

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.

J’espère que sled v1 sera sorti d’ici l’automne (avant la sortie de Duniter 2.0), si d’ici l’automne je ne vois toujours rien venir je migrerai sous RocksDB. En attendant les testeurs de la version de dev doivent prévoir de l’espace disque.

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.
Il faut que je stocke les chunk compressés dans des fichiers directement, ça occupera beaucoup moins d’espace disque et ça ne ralentira plus l’ouverture de la db.

3 J'aime

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 :laughing:

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.

4 J'aime

La v1 était pas censé sortir en Janvier 2021 ?
Il me semble t’entendre dire ça l’année dernière, mais je dois me tromper.

Si c’est bien ça, ils ont du retard

1 J'aime

'font chier tous ces gens à avoir du retard sur leurs deadlines …

Avec le correctif, les chunk compressés pèsent 112Mo pour la Ğ1 et 155Mo pour la ĞT, c’est beaucoup plus cohérent comme taille :slight_smile:

dex migrate se joue en moins de 10 minutes chez moi, je n’ai pas regardé quelle RAM ça prend.

Pour tester, assurez-vous d’être sur le commit 0b787134 ou supérieur :slight_smile:

EDIT: j’utilise l’algo deflate, utilisé notamment par le format gzip (mais pas que) qui est en réalité le nom d’un format et non pas d’un l’algo de compression :wink:
J’ai réglé la compression sur 3, le minimum étant 1 (très rapide mais taux de compression faible) et le max étant 9 (taux de compression maximal mais temps de compression très long).
Avec 3 j’ai déjà une bonne augmentation du temps de sync et une taille des chunk très raisonnable, donc je ne vais pas augmenter, peut-être même réduire à 2 je verrais.

3 J'aime

Je confirme c’est beaucoup mieux ! Merci :+1:

C’est passé avec une limitation de RAM à 2,5Go. Pas encore testé avec 2Go, mais 2.5Go c’est parfaitement acceptable.

UPDATE : La limite basse pour la RAM semble être 2.2Go.

4 J'aime

La branche dev est censée fonctionner sur un Raspberry Pi 4 actuellement ? Les commandes reset et sync m’affichent :

 $ ./target/release/duniter reset data

<--- Last few GCs --->


<--- JS stacktrace --->


#
# Fatal process OOM in insufficient memory to create an Isolate
#

J’essaie de modifier la mémoire allouée pour Node à travers NODE_OPTIONS=--max_old_space_size=2048 mais cela ne semble pas faire effet.

Une idée ?

En théorie oui, en pratique je n’ai pas testé depuis un moment, j’attendais de recevoir ma box pour rebrancher mon rpi4, mais je ne l’ai toujours pas reçue.

Cette option est déjà setté automatiquement avec la valeur 4096 :slight_smile:

Hélas non, il faudrait que je teste sur mon rpi4 pour pouvoir diagnostiquer

Ah OK, mais c’est trop. Comment puis-je mettre une autre valeur ?

On a remarqué que les nœuds de dev crashait souvent et qu’on était obligé de les restart très régulièrement. Depuis que j’ai setté statiquement max_old_space_size=4096 ça semble avoir résolu le problème.
Je ne pense pas que ce soit trop, car la plupart des utilisateurs de Duniter disposent bien d’au moins 4 Go, et souvent plus.

D’après des tests récents de @Pini , la synchro demande à minima 2,2 Go, sachant que ça ne va qu’empirer avec le grossissement de l’historique tant qu’on aura pas de système de master block, je compte indiquer dans les prérequis minimal du Duniter 2.0 qu’il faudra disposer d’au moins 4 Go de RAM.

Vu l’ampleur de ce que doit gérer Duniter et la charge grandissante autant en historique de données qu’en utilisateurs, il me semble irréaliste d’espérer que l’on puisse maintenir à moyen/long terme la possibilité de faire fonctionner un nœud Duniter avec moins de 4 Go de RAM, en tous les cas je ne compte pas m’engager là-dessus.

Là maintenant ce n’est pas possible, je peux exposer l’option afin que l’on puisse facilement tester d’autres valeurs pour trouver celle qui va bien, je ferai ça dimanche :slight_smile: