Duniter v1.8.7 release

Support Duniter-v1
,
1

Ce sujet pour tracer les choses à vérifier (et tester !), avant de pouvoir sortir une version (1.8.7 ?) de Duniter :

  • Optimisation de BMA :
  • Optimisation de la synchro :
    • Moins d’indexes sur txs.db MR!1430
    • Utilisation de batch d’insertion seulement, plutot que insert or update, si --nocautious ou full synchro MR!1429
    • Utilisation des noeuds Yunohost (BMAS avec un chemin) - MR!1432

J’ai poussé une branche test/1.8 avec toute ces MR, pour tester d’un coup :slight_smile:

@Pini as tu moyen de tester une synchro dessus et me dire si c’est mieux ? La mienne est en cours…
N’oublies pas de faire un reset data avant (pour que le mode --nocautious s’active) et d’activer le stockage des TX

@cgeek : j’ai des questions sur la synchronisation :

  • Sais tu si les piscines sont bien vidées avant une synchro ? Si oui, cela me permet d’éviter de faire des mises à jour des TX pending. Je penses que c’est une bonne approche, d’autant que les piscines sont récupérer à la fin de la synchro, non ?
1 Like
2

Oui tout est vidé.

Mais à la fin de la synchro la récupération des piscines ne fonctionne pas très bien car trop gourmande. Mais tu as poussé un correctif sur ce point, URL /wot/requirements-of ou similaire.

3

Super, dans ce cas la synchro des TX devrait pouvoir éviter les “update or insert”, pour n’utiliser que des “insert” ? Voir même des insert en batch, avec un buffer que l’on flush en fin de synchro. On n’a pas besoin qu’elles soient persister aussitôt.

Comme axe d’optimisation de la synchro, j’ai également l’idée de désactiver les contraintes BDD (null check, etc), si on est en mode --nocautious. Et tout réactiver a la fin.
A tester pour voir si on gagne vraiment.

Enfin, je me demande comment résoudre le problème mémoire que l’on rencontre actuellement…

Je ne savais pas a quoi servait ces URL BMA donc je ne penses pas avoir changer des trucs là dessus.

Je vais regarder.

4

Oulah ! On a déjà pas assez de mémoire, si en plus on rajoute des opérations en RAM… :sweat_smile:

1 Like
5

En effet.

Tu parles de SQLite pour les transactions ? Je ne sais pas quel sera le gain surtout si tu persistes à la fin seulement, mais tu peux essayer.

Pas directement cette URL mais du code commun à celle-ci et à une autre. Peut-être que je me fourvoie.

6

Non je ne crois pas que cela pose problème pour la mémoire.
Je ne parlais de tout flusher uniquement à la fin, mais en plus a la fin. Typiquement on flush toutes les 1000 ou 2000 TX, et les dernières qui restent a la fin. Cela lisse le temps consacré à la persistance des TX.

Mais je ne parle de cela car c’est le seul bout de code que je commence à bien comprendre :slight_smile: c’est peut-être dérisoire en terme de gain.

Je vous redirai après les tests. Si @Pini ou d’autypeuvent aussi tester de leur côté …

7

Je viens de tester une synchro from scratch avec la banche test/1.8 : 9000s.

Ça ne veut pas dire que c’est forcément pire qu’avant. C’est dans la fourchette haute de tous mes tests précédent. Et mon PC n’était peut-être pas en forme à ce moment. Mais en tout cas il n’y a malheureusement pas d’amélioration significative.

EDIT : Un nouvel essai à mis 8110s. Le meilleur temps de cette campagne de tests.

8

Merci @Pini

As tu moyen de laisser tourner un noeud 1.8-dev ?
Histoire qu’on puisse rester Cesium 1.7 dessus

9

C’est compliqué. Le travail de simplification d’utilisation de l’image Docker fait sur la branche dev n’a pas été porté sur la version 1.8. Et je n’utilise que Docker sur mes serveurs. Qui sont par ailleurs déjà bien chargés, donc même si j’arrive à bricoler un truc je ne suis pas certain que ce soit très utile.

Je vais mettre les mains dedans, et on verra bien.

10

ok, de mon côté tous les tests passent maintenant, avec mes optimisations sur Duniter 1.8.

Certains bugs étaient compliqué a débusquer, et même déjà présents en production dans la 1.8 (et 1.9).
=> @cgeek je penses que ca pourrait valoir le coup que tu jette une oeil sur ces 2 tickets 1446 et 1447 (et MR associées), car ces bugs sont en prod, et je ne connais pas effets possibles. Il s’agit de problème lié au revert de block : les sous-index LevelDB de SINDEX ne sont alors plus à jour (trop de ligne nettoyées pour indexForConditions, ou pas assez indexForTrimming)

dans tous les cas, je vais merge mes MR en attente sur release/1.8, dans l’après-midi.
On pourra tenter une release ensuite ! :slight_smile:

5 Likes
11

J’ai mis un noeud en ligne, buildé à partir de la branche test/1.8 : https://duniter-18-dev.pini.fr/.

En espérant que ça marche.

1 Like
12

Tu es trop fort @Pini !:slight_smile: Ca marche nickel. Bon du coup j’ai fait des modifs (d’autres MR) et donc la branche test/1.8 n’est plus jour.
Je mets à jour et je te redis.

1 Like
13

Du coup après un fork, il y a de grandes chances que les nœuds (1.8 et 1.9) n’arrivent plus à rejoindre la branche principale, car leur sous-index de sources sont corrompus (indexForConditions, indexForTriming). Ca expliquerai ces problèmes à répétition, non ?

2 Likes
14

@Pini la branche release/1.8 est à jour ! Tu peux laisser tomber la test/1.8. Je vais supprimer cette dernière.

Youpi, les tests sont OK :sunglasses:

image

Quelqu’un veut il faire la release 1.8 ?

1 Like
15

J’ai mis mon neud 1.8-dev à jour avec cette branche.

L’URL racine indique toujours 1.8.5 toutefois :

{
  "duniter": {
    "software": "duniter",
    "version": "1.8.5",
    "forkWindowSize": 100
  }
}

Pas certain que je sache faire tout seul, mais volontaire pour contribuer.

1 Like
16

Hum non bizarre. As tu bien rebuildé ton noeud ?
Par ailleurs, si tu avais déjà un noeud synchro, il faut se resynchroniser. Car certains index étaient corrompus avant les mise à jour de ce jour, par un simple fork.
Car je vois que tu n’as pas le storage dans la réponse à /node/summary (donc pas ce code)

17

Tu as raison. Dans ma précipitation j’ai fait le build sans avoir mis la branche à jour :man_facepalming:

C’est corrigé. Mais ça indique toujours 1.8.5 :

{
  "duniter": {
    "software": "duniter",
    "version": "1.8.5",
    "forkWindowSize": 100,
    "storage": {
      "transactions": true,
      "wotwizard": false
    }
  }
}

Je vais également lancer une synchro en // pour repartir propre.

18

Yes ! Et voila le travail :

4 Likes
19

Vous êtes trop fort ! bravo !!!

20

Pour faire la release je pense m’y prendre comme suit :

  1. Mise à jour de la version en 1.8.7 sur le modèle du commit 4dc2b76ed
  2. git tag v1.8.7
  3. git push && git push --tags

Ensuite il faut surveiller la CI et vérifier que tout se passe bien. Sinon boucler autant de fois que nécessaire sur :

  1. Suppression tag v1.8.7 en local et sur gitlab
  2. Corriger le problème
  3. git tag v1.8.7
  4. git push && git push --tags

Qu’est-ce que j’oublie ?