Lorsque j’essai de sync en mémoire que ce soit avec la ḡ1 ou la ḡtest, il finit toujours par s’arrêter soudainement au milieu sans demander son reste:
Ca se produit à chaque fois sur mon linux mint 20, après 4 tentatives, parfois il arrive à un downloaded presque 100% mais jamais à bout.
Je sais que c’est maigre comme retour mais je ne sais pas comment trouver plus de logs sur la cause de ces crash.
En vérifiant il semble bien me rester de la RAM de dispo pourtant.
417f04873bde5f96f8823627b1da1fd9940eff6e
La sync normal (pas en mémomire) arrive à bout mais fait laguer mon PC énormémement pendant au moins 1/2h donc j’essai de faire autrement …
Je ne pense pas, je pense plutôt à un bug qui se produirai que sur la g1-test
Non en fait le lag dont je parle c’était sur la Ḡ1 il y a 2 jours sur le même commit.
J’ai essayé d’utiliser dex migrate mais si j’ai bien compris il me faut la DB quelque part, hors je ne l’ai plus j’ai supprimé le dossier data pour passer à la gtest …
Essaye d’être plus précis stp car là je m’y perds et j’ai l’impression qu’on se comprend pas, car tu parles de plein de choses en même temps 
Ce que j’ai besoin de savoir c’est la sync qui a échoué, qui s’est arrêtée en cours, c’était sur quel commit, quelle monnaie, et ça échoué à quelle progression de l’apply ? Si ça échoue systématiquement à la même progression de l’apply alors c’est peut être un bug, c’est ça que j’ai besoin de savoir
J’ai commencé mes tests en // et je confirme que c’est un bug sur la g1-test au chunk #72000-#72249. Il me semblait bien que ça n’avait aucun rapport avec la sync en RAM.
En gros : tu ne peux pas sync un nœud GVA sur la g1-test pour le moment, il faut que j’investigue et ça peut me prendre plusieurs jours !
Non en fait il n’y a pas de bug sur la ĞT, je testai sur des données corrompues à cause de ce *** de leveldb qui se corrompt dès qu’on copie une db, c’est vraiment le pire des sgbd clé-valeur…
Toujours sur ce même commit, j’ai d’abords testé 2 fois de suite une sync en mémoire de la Ḡ1, les deux ont échoués mais pas au même endroit de l’apply, la première fois autour de 80% et la seconde fois beaucoup moins, peut être 40% mais je n’ai pas gardé ces traces, je le ferais à l’avenir.
Ensuite un sync Ḡ1 normal (pas en mémoire) a fonctionné correctement. Mais ça a duré environ 1h pendant laquelle mon PC freezais pendant 5 secondes toutes les 20 secondes, alors que j’ai un SSD et une bonne config (je n’ai pas d’élément de comparaison mais si c’est utile je peux continuer les tests plus précisément en relevant mieux chaque paramètres). Ca c’était ya 2 jours.
Je viens donc à l’instant de réessayer une sync mémoire mais ce coup ci sur le ḠTest, qui à échoué à 22% d’apply comme sur le screenshot.
Je peux refaire des tests en notant mieux les apply lors du crash j’avoue que je me souviens plus des apply des premières sync, juste que ce n’était pas au même moment …
@poka ok tu avais donc bien mélangé deux problèmes différents et indépendants c’est pour ça qu’on ne se comprenait pas.
Pour la sync en RAM, si la même sync (même monnaie, même commit) réussie sur disque c’est que tu manques de RAM. C’est sans doute lié au fait que sled occupe beaucoup d’espace disque sans compression, peut être qu’il faut 8 Go voir 16.
J’ai déjà remarqué ce problème depuis mes débuts avec Sled, d’ailleurs c’est annoncé sur leur README :
performance
- LSM tree-like write performance with traditional B+ tree-like read performance
- over a billion operations in under a minute at 95% read 5% writes on 16 cores on a small dataset
- measure your own workloads rather than relying on some marketing for contrived workloads
what’s the trade-off? sled uses too much disk space sometimes. this will improve significantly before 1.0.
3 solutions possibles :
Pour la sync qui prend 1h chez toi, ça peut être plein de facteurs, peut-être par exemple que tu es en SSD sata et pas en SSD pci-express). Hélas migrer la sync est un gros chantier qui prendra beaucoup de temps et sur lequel je ne bosse pas en ce moment vu que je suis sur lu prototype de GVA, j’ai pas de solution court-terme 
@poka fausse alerte il n’y a pas de bug sur la g1-test, c’est cette mer*e de leveldb qui se corrompt à la moindre copie qui m’a induit en erreur…
EDIT: en fais si il y avait bien un problème sur la g1-test, vois plus bas.
Je viens de faire une sync complète (sur disque) de la g1-test sur mon pc de dev sur la branche gva-proto-2 et tout s’est bien passé. Ça a pris très exactement 21 minutes, sachant que c’était la récup des chunk sur le réseau qui semblais être le frein.
En gros : fait une sync de la g1-test sur disque, et si ça doit te prendre 1h en pouvant rien faire d’autre sur ton pc, ben fait une pause des écrans pendant la sync, ça fait du bien aussi 
/dev/shm ne remplit pas forcément toute la RAM, il faut vérifier sa taille avec df -h. Chez moi il fait 8 Go alors que j’ai 16 Go de RAM. (c’est peut-être parce que j’ai ajouté une barrette et qu’il est resté sur l’ancienne valeur)
Il y avait bien un problème avec la sync de GVA sur la g1-test, mais seulement quand on sync avec dex migrate. Ma sync réussie était avec duniter.
Comme le code d’indexation des blocs est le même dans les 2 cas, et que j’ai régulièrement des soucis liés à la corruption de la DB leveldb, j’en ai déduit qu’il n’y avait pas de bug et que c’était ma DB leveldb qui était corrompue.
Reprenant mes dev aujourd’hui, j’avais besoin de tester l’indexation d’une nouvelle donnée : les balances des comptes. Donc je compile en release et je tente un dex migrate, et là c’est le drame : même erreur qu’hier sur le même chunk → ce n’était donc pas un problème de corruption de données…
Cela étant impossible (puisque c’est le même code d’indexation via Duniter ou via dex), j’en ai conclus qu’il y avait non pas 1 mais 2 problèmes. Et en effet, la syc via Duniter n’activait plus l’indexation de la db gva, même avec l’option GVA. Une fois ce second problème corrigé, j’ai retenté une sync via duniter et j’ai bien eu la même erreur qu’avec dex : ouf, les deux méthodes ont bien le même comportement.
Ce problème, c’est à cause du petit malin qui a eu la mauvaise idée de soumettre un output invalide : https://g1-test.duniter.org/blockchain/block/71329
J’avais déjà rencontré ce problème dans Dunitrust, et à l’époque j’y avais passé une semaine entière.
Et j’avais justement repris le code de Dunitrust pour gérer ce cas. Sauf que dans Dunitrust, je gérai ça en partie via la grammaire PEG, grammaire que j’ai dû refondre lors de l’intégration dans Duniter car elle comportait une faille de sécurité (qui était connue et tracée dans le projet Dunitrust).
J’ai dû réadapter le contournement de manière a qu’il n’utilise plus la grammaire.
Bref, j’ai créé un TU pour verrouiller le cas, voir le commit : fix(docs-parser):TxOutput: handle invalid script without grammar (10726648) · Commits · libs / dubp-rs-libs · GitLab
Une seule soirée pour contourner une grosse difficulté qui m’avait demandé une semaine dans Dunitrust.
Et certaines mauvaises langues osent dire que le Dunitrust n’a servi à rien, que c’était du temps perdu, ces personnes-là ne réalisent pas à quel point tout le travail de fonds réalisé sur Dunitrust m’est ultra utile aujourd’hui.
Si Dunitrust n’avait pas existé, il n’y aura pas de prototype de GVA aujourd’hui, et j’en serai encore vraiment très loin (plus d’un an).
