Voilà : https://git.duniter.org/admins/duniter-infra/-/merge_requests/55
La synchro a également échouée 
Progress:
Milestones: [||||||||||||||||||||] 100 %
Download: [|||||||||||||||||| ] 93 %
Apply: [|||||||||||||||||| ] 91 %
Sandbox: [ ] 0 %
Peers: [ ] 0 %
Status: Getting chunk #2426/2605 from 606500 to 606749 on peer g1.le-sou.org
<--- Last few GCs --->
[7:0x56523a2959c0] 31477506 ms: Mark-sweep 1230.2 (1349.5) -> 1230.1 (1330.0) MB, 1452.2 / 0.0 ms (average mu = 0.389, current mu = 0.000) last resort GC in old space requested
[7:0x56523a2959c0] 31478892 ms: Mark-sweep 1230.1 (1330.0) -> 1230.1 (1330.0) MB, 1386.4 / 0.0 ms (average mu = 0.241, current mu = 0.000) last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x154f5671e6c1 <JSObject>
0: builtin exit frame: parse(this=0x154f567119f9 <Object map = 0x3f2b70a042a9>,0x22a1bad826f1 <undefined>,0x1ea248e02201 <Very long string[1994533]>,0x154f567119f9 <Object map = 0x3f2b70a042a9>)
1: /* anonymous */ [0x1b9dd7daab21] [/duniter/duniter/node_modules/request/request.js:1145] [bytecode=0xd8e113c1d69 offset=396](this=0x38167cd9e499 <Request map = 0x21dbf8f86f01>)
2: argumen...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Aborted (core dumped)
Je suis passé en mode copie. C’est beaucoup plus rapide. Ça y est g1.duniter.fr est synchronisé et fonctionnel.
Je me suis aidé de cette documentation pour comprendre l’installation Docker https://forum.duniter.org/t/g1-node-installation-maj-resync/7376
5 Likes
t’ as vérifié les derniers chunks/blocs du duniter_default copié ? sont ils bien à jour ?
Non, pourquoi ?
si t’ as pas synchro mais copier le dossier default personnalisé, il est fort possible que les chunks n’ évoluent pas, restent figé et puis donc le noeud carencé des transactions non présentes après la date de la copie alors donc vérifie si possible car de notre coté ça a systématiquement donné des noeuds calculants sans les derniers blocs. probablement une question de droit en ecriture…
À ta convenance, le merge de
https://git.duniter.org/admins/duniter-infra/-/merge_requests/56
activera le changement en question
1 Like
Les chunks ne semble pas évoluer.
Cependant, l’indexation des transactions semble toujours avoir lieu :
silkaj -ep g1.duniter.fr money history GfKERHnJTYzKhKUma5h1uWhetbA8yHKymhVH2raf2aCP:J1k
[…]
│ 2023-08-13 13:09:31 │ TENGx7Wt…:AXW │ 5 │ 0.468 │ REMU:651501:652000
[…]
Tu parles de quel chunk ? de synchro ou autre ? dans quel dossier ?
As tu regarder à quoi ils servent dans le code ?
@kimamila concernant la procédure dont il était question càd copier coller directement duniter_default pour éviter de laborieuses synchronisations, il est question des chunks de données duniter brutes autrement dit la chaine de blocs avec ses transactions monnaie / certifications / commentaires de .
le dossier /G1 en fait
Si tu fais une copie des fichiers BDD issus d’une instance synchronisé, tu n’as aucunement besoin des chunk de synchronisation. Seule la phase de synchronisation utilise ces fichiers. Ensuite, Duniter a son propre mécanisme de partage des blocs, par l’API ws2p.
Sauf erreur. @cgeek est-ce bien cela ?
De mémoire oui, les chunks c’est juste pour la synchro initiale.
Intéressant, donc, la copie des chunks ne serait pas nécessaire pour cette opération de copie/synchro ?
tant que personne n’ essaie de se synchroniser sur le noeud initialement copié, ce qui expliquerait les synchros incompletes à 9o%
je verai donc deux possibilités futures, soit permettre la sur-écriture des chunks non synchronisés, soit modifier les modalités de synchro, par exemple no-chunk
ps/ ou bien troisiemement, exclure les noeuds copiés des tentatives de synchro
L’explication communément admise aux synchronisations qui ne finissent pas est un problème de mémoire : problème de gestion de la mémoire par Duniter et/ou Node.js ou manque de mémoire allouée au processus.
Il me semble que l’ensemble des blocs de la blockchain est répliquée dans le dossier data sous forme de base de donnée.
1 Like
ce type d’ erreur est advenue aussi sur des nodemax à 1o Giga d’ après ce je lis ici.
le nodemax est un débridage nécessaire sur les version de node.js bloquées à 512M
Et ils sont bien constitué à la volée, lorsqu’un noeud les demandes ? @ness sous entend que non, mais je ne vois pas la logique (sans même regarder le code) : cela empêcherait toute synchro depuis une monnaie qui vient de se lancer…
@ness stp, peux tu arrêter tes déductions faites sans vérification. Je te fais un message pour résumer avec toi cela, tranquillement et paisiblement 
2 Likes
Pas nécessaires en effet. Ce qui rend la synchro plus longue car il faut alors taper sur le réseau pour les obtenir.
D’ailleurs si d’aventure il manque des bouts de chunk en local ou que les chunks ne se chaînent pas bien (mauvais hash de bloc précédent) alors la chunk est invalidée et Duniter va la chercher sur le réseau également.
Oui : les blocks sont tous enregistrés dans LevelDB, et sont fournis sur demande.
Les fichiers de chunk sont juste un intermédiaire temporaire qui évite de les télécharger.
1 Like