J’aurais du y penser avant, pour synchroniser Duniter plus rapidement vous pouvez faire la sync en mémoire vive grâçe à /dev/shm (uniquement sous linux).
Voici comment faire :
Faite votre synchro avec l’option --home /dev/shm/duniter. Par exemple :
Il est indispensable de bien penser à copier les données après la sync (étapes 2 et 3), sinon quoi vous perdrez toutes les données au prochain redémarrage de votre ordinateur !
Les pro du bash peuvent nous faire un petit script ?
Pour l’utiliser il faut renommer le fichier sync_duniter.sh.json en sync_duniter.sh
On peut le lancer l’option --help pour le détail des options
./sync_duniter.sh --help
Usage: ./sync_duniter.sh [options]
-h --help : display this help and exit
-s --start : start duniter at the end of the synchronization
-n --node node_adress : node used to start synchronization (default g1.duniter.org)
-m --mdb mdb
-a --all-data : include peers and mempool
Pour l’instant je ne l’ai lancé que dans un ubuntu 20.04. La synchro s’est faite en 35 minutes.
Le dossier /dev/shm/duniter fait 1.2Go, il faut donc 1.2 Go RAM de libre
je sais que beaucoup sont concentrés sur la V2 mais je viens de resync mon noeud en mémoire vive grace à ce topic et il y a semble-t-il une typo dans la commande de copie du dossier data et cela conduit à créer un sous-dossier data (avec les données synchronisées) dans le dossier data existant.
il faut plutôt faire :
Enfin bon, mon nœud est de nouveau en ligne après un blackout qui durait depuis l’arrêt de la blockchain début avril … (Qui a dit que je n’étais pas assez attentif ? )
J’ai voulu tester le script de @ji_emme, mais il semble planter vers la fin dans mon cas
Juste pour info, le serveur est un duniter 1.8.5 en ARM (duniter-server-v1.8.5-linux-armv7l.deb) sur une VM Oracle Cloud (always free) 4 cpu ARM64, 24GO ram.
J’ai tenté de faire une sync normale, en augmentant la mémoire que nodejs peut utiliser, mais j’ai de nouveau eu un plantage (mais plus loin qu’avant):
J’ai utilisé la variable d’environnement NODE_OPTIONS avec “–max-old-space-size=3064” pour tenter de solutionner le soucis, mais cela ne semble pas suffisant… et si je tente de mettre plus de mémoire, nodejs plante instantanément (a priori, sans doute du au fait que c’est une version 32 bits de nodejs… à vérifier)
Voici ce que j’ai eu comme logs:
➜ ~ export NODE_OPTIONS="--max-old-space-size=3064"
➜ ~ duniter sync g1.mithril.re:443
2023-04-05T19:00:58+02:00 - debug: Plugging file system...
2023-04-05T19:00:58+02:00 - debug: Loading conf...
2023-04-05T19:00:58+02:00 - debug: Configuration saved.
2023-04-05T19:00:58+02:00 - debug: Opening SQLite database "/home/ubuntu/.config/duniter/duniter_default/duniter.db"...
2023-04-05T19:00:58+02:00 - debug: Now open indexers...
2023-04-05T19:00:58+02:00 - debug: Opening SQLite database "/home/ubuntu/.config/duniter/duniter_default/txs.db"...
2023-04-05T19:00:58+02:00 - debug: Opening SQLite database "/home/ubuntu/.config/duniter/duniter_default/peers.db"...
2023-04-05T19:00:58+02:00 - debug: Upgrade database...
2023-04-05T19:00:59+02:00 - info: Block resolution: 0 potential blocks for root block...
Progress:
Milestones: [||||||||||||||||||||] 100 %
Download: [||||||||||||||||||| ] 98 %
Apply: [||||||||||||||||||| ] 96 %
Sandbox: [ ] 0 %
Peers: [ ] 0 %
Status: GOT chunck #2412/2462 from 603000 to 603249 on peer fania.g1server.net
<--- Last few GCs --->
[38996:0x35d6838] 11325971 ms: Mark-sweep 848.2 (1279.2) -> 848.2 (1238.2) MB, 1090.7 / 0.0 ms (average mu = 0.895, current mu = 0.000) last resort GC in old space requested
[38996:0x35d6838] 11327046 ms: Mark-sweep 848.2 (1238.2) -> 848.2 (1212.2) MB, 1075.3 / 0.0 ms (average mu = 0.807, current mu = 0.000) last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x34aeae9c]
Security context: 0x521126ed <JSObject>
1: split [0x5210b68d](this=0x2ec0b75d <String[56]: 2257:0:SIG(3v63gshw3jtAfFEqqzGMiWkb2rY6gJFwCTcqpBUSGBrp)>,0x52169059 <String[1]: :>)
2: addLinked [0xf452d66d] [/opt/duniter/app/lib/dal/indexDAL/sqlite/SqliteTransactions.js:~70] [pc=0xc8068960](this=0x346145c5 <SqliteTable map = 0x56b5ffbd>,tx=0x29a04421 <the_hole>,block_number=0x29a04421 <the_hole>,time=0...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
/usr/bin/duniter: line 15: 38996 Aborted (core dumped) $NODE "$DUNITER_DIR/bin/duniter" "$@"
Du coup, il m’est actuellement impossible de faire une sync avec la seule version duniter pour ARM que j’ai trouvée (duniter-server-v1.8.5-linux-armv7l.deb) :-/
Quelqu’un aurait une suggestion ou une version arm64 que je puisse installer ? (a priori; le .deb armv7, c’est seulement du 32 bits)…
Merci pour ton aide, mais j’ai beau mettre l’un ou l’autre, pstree me dit que la commande node ne le prend pas en compte (node est lancé sans l’option --max-old-space-size=8192) même si env a bien les variables dans le container…
A chaque fois que mon nœud V1 se desync, j’ai des boutons et des bouffées de chaleur. Car je sais ce qui m’attends. J’ai tenté plein de trucs en quelques jours sans succès. Je réessaierai quand on manquera de nœuds, car c’est trop chronophage là.
)
J’ai tenté plein de trucs en quelques jours sans succès. Je réessaierai quand on manquera de nœuds, car c’est trop chronophage là. 