Synchroniser Duniter plus rapidement

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 :

  1. Faite votre synchro avec l’option --home /dev/shm/duniter. Par exemple :
duniter --home /dev/shm/duniter sync g1.duniter.org
  1. Une fois la synchronisation terminée, copiez le dossier data :
cp -r /dev/shm/duniter/duniter_default/data ~/.config/duniter/duniter_default/data
  1. Si vous souhaitez récupérer également les peers et les mempool, copiez également les 3 db SQLite :
cp /dev/shm/duniter/duniter_default/peers.db ~/.config/duniter/duniter_default/peers.db
cp /dev/shm/duniter/duniter_default/duniter.db ~/.config/duniter/duniter_default/duniter.db
cp /dev/shm/duniter/duniter_default/txs.db ~/.config/duniter/duniter_default/txs.db

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 ?

6 Likes

Je m’en suis fais un pour ceux que ça intéresse.

sync_duniter.sh.json (2,4 Ko)

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

6 Likes

Salut, le fichier .sh est-il utilisable directement ?

Ou faut-il apporter des réglages précis pour notre noeud (Url, BMA, etc… ?)

oui il est utilisable directement mais il ne configure pas le noeud et ne modifie pas non plus la conf du noeud.

2 Likes

Ok, super ! Merci bien :slight_smile:

Passe une bonne fin de journée, amicalement, Francis

6 messages ont été scindés en un nouveau sujet : Arret inopiné de la sync duniter

Salut,

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 :

cp -r /dev/shm/duniter/duniter_default/data ~/.config/duniter/duniter_default/

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 ? :stuck_out_tongue_winking_eye:)

4 Likes

Bonjour,

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.

Je me retrouve avec ces logs:

➜  scripts ./sync_duniter.sh -a
Stopping duniter_default daemon...
duniter_default daemon stopped.
2023-04-05T15:32:04+02:00 - debug: Plugging file system...
2023-04-05T15:32:04+02:00 - debug: Loading conf...
2023-04-05T15:32:04+02:00 - debug: Configuration saved.
2023-04-05T15:32:04+02:00 - debug: Opening SQLite database "/dev/shm/duniter/duniter_default/duniter.db"...
2023-04-05T15:32:04+02:00 - debug: Now open indexers...
2023-04-05T15:32:04+02:00 - debug: Opening SQLite database "/dev/shm/duniter/duniter_default/txs.db"...
2023-04-05T15:32:04+02:00 - debug: Opening SQLite database "/dev/shm/duniter/duniter_default/peers.db"...
2023-04-05T15:32:04+02:00 - debug: Upgrade database...
2023-04-05T15:32:04+02:00 - info: Block resolution: 0 potential blocks for root block...

Progress:  

Milestones:   [||||||||||||||||||||] 100 %
Download:     [|||||||||||||||     ] 77 %
Apply:        [|||||||||||||||||   ] 86 %
Sandbox:      [||||||||||||||||    ] 84 %
Peers:        [                    ] 0 %

Status: Peers...(node:34555) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 pipe listeners added. Use emitter.setMaxLisGetting chunck #2120/2462 from 530000 to 530249 on peer g1v1.p2p.legal
<--- Last few GCs --->

[34555:0x36e2870]  6330978 ms: Scavenge 667.3 (721.0) -> 666.5 (721.0) MB, 3.4 / 0.0 ms  (average mu = 0.256, current mu = 0.175) allocation failure 
[34555:0x36e2870]  6330995 ms: Scavenge 667.3 (721.0) -> 666.5 (721.0) MB, 3.7 / 0.0 ms  (average mu = 0.256, current mu = 0.175) allocation failure 
[34555:0x36e2870]  6330999 ms: Scavenge 667.4 (721.0) -> 666.5 (721.5) MB, 3.3 / 0.0 ms  (average mu = 0.256, current mu = 0.175) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x38a926ed <JSObject>
    0: builtin exit frame: parse(this=0x38a8c039 <Object map = 0x51f85155>,0x5780438d <undefined>,0xc3c04101 <Very long string[989783]>,0x38a8c039 <Object map = 0x51f85155>)

    1: /* anonymous */ [0x57f337e5] [/opt/duniter/node_modules/request/request.js:1145] [bytecode=0x23a79929 offset=396](this=0xdd169fe1 <Request map = 0x34f0adf9>)
    2: arguments adaptor frame: 1->0
    3: emit [0x38aa899d] ...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
/usr/bin/duniter: line 15: 34555 Aborted                 (core dumped) $NODE "$DUNITER_DIR/bin/duniter" "$@"
2023-04-05T17:17:37+02:00 - debug: Plugging file system...
2023-04-05T17:17:37+02:00 - debug: Loading conf...
2023-04-05T17:17:37+02:00 - debug: Configuration saved.
2023-04-05T17:17:37+02:00 - warn: Data successfully reseted.

Ca semble être un problème de mémoire, mais je ne sais pas trop à quel niveau ??

A priori, ça ne devrais pas être une limite de /dev/shm vu qu’il me reste ±10GO:

➜  scripts df -h   
Filesystem      Size  Used Avail Use% Mounted on
...
/dev/sda1       194G   16G  179G   8% /
tmpfs            12G  2.0G  9.8G  17% /dev/shm
...

Du coup, je ne sais pas quel setting on peut adapter pour le soucis de mémoire ?

1 Like

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)…