Question: ces 4Go sont-ils nécessaires uniquement pour la synchro, ou également pour la résolution de forks ?
J’ai resynchronisé mon noeud (1Go de RAM) en faisant la synchro sur le laptop (8Go) puis en copiant le dossier duniter_default.
Par ailleurs, je pense mettre en place un backup recurrent de duniter_default pour pouvoir repartir d’un état à -1mois en cas de fork non résolu.
Dans ces cas d’usage (pas de synchro complète sur le noeud), les 4Go s(er)ont-ils tout de même nécessaires ?
Ce serait l’idéal de faire ça. Malheureusement, chez moi, un reset data + sync en ram est plus rapide qu’une sync sur HDD…
Si j’ai bien compris, une sync sur une blockhain existante mais bloquée, ne va recharger que les blocs divergeants, non ? C’est censé être plus court en temps que de recharger toute la blockchain ?
Ou bien y a t-il un paramètre que j’ignore pour dire “sync uniquement les x derniers blocs” ?
Sur une machine qui a exactement 4Go de RAM, ça empêche le programme de démarrer visiblement (erreur ci-dessus).
OK j’ai trouvé dans le code, j’ai modifié à 4000 et ça passe. Mais entre 4000 et 4096 c’est assez aléatoire, parfois ça passe parfois non. Je suppose que c’est lié à l’activité système.
edit : bon, mais la synchro ne passe pas pour autant, ça bloque à “Milestone: 99%”. Pourtant la mémoire n’est pas saturée.
edit 2 : en fait ça plante dès que le processus tente de dépasser les 2Go de mémoire réellement utilisée (pas virtuelle).
De ce que j’ai cru comprendre par mon experience :
souvent (1x/semaine) un bloc est considéré comme invalide, reste en mémoire et bloque toute résolution de fork. Redémarrer Duniter fait la job, j’ai une tâche cron qui redémarre tous les jours.
parfois, un bloc est considéré invalide même après redémarrage, reset, etc. Dans ce cas, une sync sans reset data n’a jamais fonctionné chez moi. En revanche, remplacer les donnees par une archive de donnees plus anciennes a fonctionné, Duniter est allée chercher les blocs manquantes comme une grande.
Pourtant lorsque je bride mon instance Docker de dev à 2.5 Go de RAM la synchro complète fonctionne.
Je n’ai pas encore remarqué ça. Mais il est vrai que j’ai rarement laissé tourner une de mes instances plus d’une semaine sans redémarrage. Je vais surveiller en les maintenant up autant que possible.
Sait-on jusqu’à quelle ancienneté ce mécanisme peut fonctionner ?
Si tu as un OOM kill dès que ça dépasse 2Go, c’est plus cohérent avec mes derniers essais (minimum requis 2,2 Go), et c’est peut-être que ta RAM est déjà bien occupée par ailleurs. As-tu configuré du swap pour donner un peu de marge ?
Je viens de regarder la date du dernier démarrage de mon container docker Duniter Ğ1, pensant que c’était il y a longtemps, car il tourne comme une horloge, mais ô surprise, il a rebouté cette nuit !
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
<--- Last few GCs --->
[7:0x562be7030960] 372327370 ms: Scavenge 1308.2 (1378.9) -> 1304.6 (1386.9) MB, 3.7 / 0.0 ms (average mu = 0.373, current mu = 0.392) allocation failure
[7:0x562be7030960] 372327451 ms: Scavenge 1312.7 (1386.9) -> 1305.2 (1386.9) MB, 3.1 / 0.0 ms (average mu = 0.373, current mu = 0.392) allocation failure
[7:0x562be7030960] 372327496 ms: Scavenge 1313.1 (1386.9) -> 1305.9 (1386.9) MB, 3.2 / 0.0 ms (average mu = 0.373, current mu = 0.392) allocation failure
<--- JS stacktrace --->
Aborted (core dumped)
Le container se relance automatiquement en cas d’erreur. Ici on voit un problème de mémoire. Pourtant j’ai 8go. Je vais installer un outil de monitoring pour comprendre ce qui se passe…
On pourrait le penser, mais je ne crois pas :
Il semble que ce soit effectivement la synchro qui demande le plus de RAM. Très probablement qu’actuellement Duniter consomme très peu de RAM hors-synchro, mais je ne garantis pas qu’il en restera ainsi 
Ça fait bien longtemps que la sync partielle ne fonctionne plus, et je n’ai pas les compétences pour diagnostiquer ça. Je peux coder de la sync partielle pour les DB Rust, mais tant que la db leveldb restera (et elle restera encore bien après duniter 2.0), je ne serai pas en capacité d’avoir une sync entièrement partielle.
D’accord je vais donc baisser la valeur par défaut. Entre temps je viens d’exposer l’option --max-old-space-size dans mon dernier commit, tu peut donc testes d’autres valeurs sans recompiler
Ha tiens c’est curieux 
En théorie aussi loin que possible. Le nœud rattrape les blocs petit à petit via WS2P, j’ai déjà rattrapé plus de 20000 blocs comme ça, mais ça prend plusieurs heures.
Je testerai sur mon raspberry pi 4 avec 4Go de RAM dès que j’aurais enfin reçu ma box. Je ferai de mon mieux pour que Duniter fonctionne dessus, et corrigerai ce qu’il y a à corriger, mais tant que je suis en partage de connexion via mon tel c’est compliqué 
Bon je pense avoir trouvé : pour l’instant Raspbian est en 32bits, ce qui empêche l’utilisation de plus de 2GB par process.
Je vais essayer une Raspbian x64, c’est encore en beta mais pour ce que je veux faire ça ira très bien.
Bon ben ça ne compile pas au commit 251bb84a sur Raspbian x64. La stack ci-jointe à toutes fins utiles.
stacktrace.txt (516,9 Ko)
Est-ce que Raspbian x64 correspond à l’architecture Debian « arm64 » ? Si oui, je viens de faire un test de build de ce commit (avant la restriction de GVA à x86_64) sur une machine Buster arm64, et c’est allé au bout.
UPDATE : non, désolé, je retire ce que j’ai dit. J’avais fait une fausse manip avec git et c’est le dernier commit qui avait été compilé. En ré-essayant sur 251bb84 j’ai la même erreur que @cgeek :
signal: 11, SIGSEGV: invalid memory reference
Ça fait passer de armv7l à aarch64. Ça a l’air de marcher sur mon Pi 4 avec Raspbian Buster.
C’est bien aarch64. Je suis en train de tester sous différentes configurations et ferai une MR si besoin. Mais sous certaines conditions j’arrive à synchroniser.
error: could not compile `duniter-gva`
Je ne sais pas pourquoi GVA ne compile pas sur aarch64, mais de toute façon j’avais prévu depuis le début de ne pas inclure gva sur architecture micro-pc (arm et aarch), j’avais juste pas fait ça dans le code car je travaillais plus sur arm depuis longtemps.
J’ai poussé dans la nuit un commit qui inclus GVA conditionnellement en fonction de l’architecture cible. Graçe à ça vous devriez pouvoir compiler duniter dev sous aarch64, et même avoir besoin de moins de RAM pour synchroniser (car c’est la synchro de GVA qui augmente le besoin en RAM lors de la sync).
En réalité, ce n’est pas lié à un commit en particulier, entre-temps @cgeek a trouvé, c’est un bug de rustc: cargo build : failed to "SIGSEGV: invalid memory reference" · Issue #6489 · rust-lang/cargo · GitHub
Mon but est d’optimiser GVA pour pouvoir répondre à beaucoup de requêtes clientes très rapidement, afin que les utilisateurs des logiciels clients est une expérience fluide. Dans cette optique, je choisis volontairement de prioriser la rapidité d’exécution, au détriment des ressources utilisées (RAM, cpu, espace disque).
Ce que je veux dire c’est que si GVA consomme beaucoup de ressource c’est un choix par design, j’aurais pu tout aussi bien faire en sorte que GVA consomme très peu de ressource, mais ça aurait nécessairement impliqué une API plus lente.
Je considère qu’améliorer l’expérience des utilisateurs de la Ğ1 sur leurs logiciels clients (expériences clairement mauvaise pour le moment) est plus important que de consommer peu de ressources côté serveur.
Afin que les nœuds Duniter sur micro-pc puissent continuer d’exister, et de participer au calcul et à la vérification des blocs, il me semble plus pertinent de désactiver GVA sur ce type de machine
En plus, ça m’ouvre la porte à des optimisations spécifiques pour architecture x86, afin de rendre GVA encore plus rapide.
J’ai du mal à comprendre ce résultat, car sur le Raspberry même avec 4Go de RAM ça ne passe pas.
Ça bouge assez vite en ce moment. Avec la dernière image de dev 2.5Go ne suffisent plus (OOM kill vers 75%). Je viens de refaire le test avec 3Go et c’est passé :
$ docker volume rm duniter_etc duniter_data
$ docker run --rm -it --name duniter-synchro -m 3g -v duniter_etc:/etc/duniter -v duniter_data:/var/lib/duniter --entrypoint /usr/bin/duniter duniter/duniter:dev sync g1-test.duniter.org --no-interactive
2021-05-25T11:27:55+00:00 - warn: No configuration loaded
2021-05-25T11:27:55+00:00 - info: mode=Sync
2021-05-25T11:27:55+00:00 - info: open duniter databases...
2021-05-25T11:27:55+00:00 - info: Databases successfully opened.
2021-05-25T11:27:55+00:00 - info: Current block: no blockchain
2021-05-25T11:27:55+00:00 - info: start dbs threadpool...
2021-05-25T11:27:55+00:00 - info: Duniter sever started.
2021-05-25T11:27:55+00:00 - info: start duniter modules...
2021-05-25T11:27:55+00:00 - info: generated self endpoints: []
2021-05-25T11:27:56+00:00 - info: Block resolution: 0 potential blocks for root block...
2021-05-25T11:27:56+00:00 - info: Connecting to address g1-test.duniter.org :443...
2021-05-25T11:27:56+00:00 - info: Try with g1-test.duniter.org:10900 238pNf
2021-05-25T11:27:56+00:00 - info: [GAwvkG1D] ⬇ PEER 238pNfpk 760390-0
2021-05-25T11:27:56+00:00 - info: [GAwvkG1D] ✔ PEER 238pNfpk 0-E3B0C4
2021-05-25T11:27:56+00:00 - info: Sync started.
2021-05-25T11:27:56+00:00 - info: Getting remote blockchain info...
2021-05-25T11:27:56+00:00 - info: Peers...
2021-05-25T11:27:57+00:00 - info: Downloading Blockchain...
...
2021-05-25T11:55:40+00:00 - info: Sync finished (duration 1664332 ms).
2021-05-25T11:55:41+00:00 - info: Database closed.
2021-05-25T11:55:41+00:00 - info: Database closed.
C’est pas normal il y a un souci, si tu es bien sur le dernier commit tu n’as pas GVA, dont la sync devrais prendre moins de 2 Go, tu as testé avec quelle valeur pour --max-old-space-size ?