Urgent : problèmes majeurs pour les utilisateurs

[kimamila]

Je penses qu’on a plusieurs soucis importants, auxquels sont confrontés d’avantage les utilisateurs non experts. Nous avons un biais ici car nous savons contourner les problèmes réseaux que nous voyons. Mais l’utilisateur lambda. Cf le forum.monnaie-libre.fr

Ces problèmes révèlent aussi le manque de tests de notre côté, et des lacunes dans l’estimation des impacts pour les utilisateurs dans les décisions prises. Nous devons (ensemble) être bien vigilant, bien tester, etc.
Je me dis que peu de gens ont du tester Cesium 1.7 et Duniter 1.8.7 pour qu’on voit tout cela que maintenant.

Dans tous les cas il faut agir assez vite car la situation est désastreuse, selon moi, pour l’utilisateur moyen.

• réseau Duniter :
  • Il faut plus de noeuds 1.8.7, sinon les optimisations de perfs ne sont pas visibles, et on tombe sur des timeout (certaines requêtes n’aboutissent pas après 40s). cc @smith-v1 : mettez a jour vos noeuds 1.8 svp !
  • le noeud g1.duniter.org pose de gros problème car il est load-balancé sur plusieurs noeuds. Cesium est perdu (et les utilisateurs surtout) car parfois les piscines change, d’un lancement à l’autre : les transactions en attente disparaissent et c’est impoiz debugger car l’utilisateur si l’utilisateur est sur g1.duniter.org, qui peut cacher plusieurs versions de Duniter…
    => Est-ce possible de revenir à un seul noeud ? Si possible 1.8.7. Qui sait faire cela ?
• les noeuds 1.9 (BMA) :
  • à vérifier si cela vient de là, mais a mon avis les transactions ne sont pas triées. Qui peut prendre le temps de vérifier ? Si cela se confirme, il faudra ajouter des tests pour vérifier l’ordre des TX.
  • qui peut aider à repoter les modifs 1.8.7 de performances ? J’ai déjà bien avancé sur la branche develop.
  • ne peut-on pas débrancher les noeuds 1.9 tant que les tests complets n’ont pas été passé ? On est quand même sur une version de dev, et l’on boit que cela pose problème. Ginkgo en sera perturber, je ne sais bien, mais au moins on prend les choses dans l’ordre. La tout a été bricoler, avec Duniter 1.9 et pas entièrement tester…
• Cesium 1.7.6 :
  • il doit y avoir un bug car parfois Cesium tente de se connecter sur un endpoint GVA. Peut-être du au regexp utilisée, car j’autorise maintenant un /path pour les endpoint BMA (ex: Yunohost)
  • autre bug : dans “Mes opérations” parfois les opérations ne sont pas téléchargées. Il faut rafraîchir a la main.

Tous ces éléments me semblent assez urgent.

[vit]

J’ai relayé sur le forum monnaie-libre :

Mise à jour importante de Duniter en version 1.8.7

@kimamila

=> Est-ce possible de revenir à un seul noeud ? Si possible 1.8.7. Qui sait faire cela ?

ping @immae ?

Il est évident que le load balancing était une solution temporaire et qu’il se télescope maintenant avec celui de Cesium 1.7.x.
Le serveur g1.duniter.org étant en 1.8.7 il devrait pouvoir encaisser la surcharge des Cesium < 1.7.x…

[immae]

Pour autant que je sache il n’avait pas vocation à être temporaire (en tout cas il n’a pas été implémenté comme tel)

Je veux bien supprimer le load balancer, mais par quoi faut-il le remplacer ?
Est-ce qu’il faut uniquement servir le nœud local ?
Est-ce qu’on prévoit de remettre le load balancer à un moment et je le remplace juste par un load balancer à un seul nœud le temps que les autres soient mis à jour ?
Je peux aussi ajouter une “règle” de sanity qui vérifie la version actuelle pour déterminer si un nœud est “utilisable” (et ainsi chacun peut mettre à jour son nœud à son rythme.

[vit]

@kimamila a implémenté la selection aleatoire d’un serveur dans Césium 1.7.x. Effectivement cela n’est pas tout a fait la même chose et peut peut-être se combiner avec le load balancer. Je vous laisse voir ensemble la meilleure option.

[immae]

Pardon, mon but n’était pas de lancer une discussion ou de proposer une autre solution. Je n’ai absolument pas la “big picture” du projet . Je m’assurais juste que je comprenais correctement ce dont il était question (par exemple, je ne savais pas que le front s’occupait maintenant de faire le load balancing)

Si vous me dites que le LB n’a plus lieu d’être je le supprime, il faut juste me dire par quoi je dois le remplacer .
Ou plus précisément: vers quoi dois-je faire pointer le nœud en g1.duniter.org une fois que j’aurai supprimé le LB ?

[tuxmain]

@kimamila

à vérifier si cela vient de là, mais a mon avis les transactions ne sont pas triées.

D’après ./gql/src/queries/txs_history.rs les transactions devraient être triées par numéro de bloc d’écriture :

// both_txs étant les txs envoyées suivies des txs reçues
both_txs.sort_unstable_by(|(_, db_tx1), (_, db_tx2)| {
    db_tx1
        .written_block
        .number
        .cmp(&db_tx2.written_block.number)
});

Edit: mais il y a d’autres requêtes pour l’historique des txs, de laquelle est-il question ?

[jytou]

Pour info après màj vers 1.8.7, j’ai la même erreur que moul :

2023-08-06T21:48:20+02:00 - error: Error: SQL error “SQLITE_ERROR: no such column: issuer” on query "
BEGIN;
CREATE TABLE IF NOT EXISTS txs (
…

C’est parti pour une resynchro, en espérant que ça passe…

[Damery]

Duniter V1.8.7 installé mais pas moyen de synchroniser … Des conseils pour y arriver ?
(Linux mint, 4 Mo de mémoire, 3 cpu)
Et je vois beaucoup de noeuds en V1.9.0, est-ce bien de migrer en 1.8.7 ?
Merci d’avance.

[PiNguyen]

Salut j’ai ce message d’erreur après la validation d’un virement dans l’extension cesium 1.7.6 dans Firefox :

[aya]

@immae

Ou plus précisément: vers quoi dois-je faire pointer le nœud en g1.duniter.org une fois que j’aurai supprimé le LB ?

A mon avis cela devrait pointer vers un noeud local en 1.8.7 hébergé dans le domaine duniter.org, ou sinon vers un noeud en 1.8.7 comme g1.e-is.pro.

@kimamila

qui peut aider à repoter les modifs 1.8.7 de performances ? J’ai déjà bien avancé sur la branche develop.

Je veux bien regarder, mais je voie pas de quelle branche develop tu parles. Je prépare une MR en dev avec les modifs de la 1.8.7 ?

[edit] ok j’ai trouvé la branche develop en question, tu parlais de cesium, je pensais que tu parlais de reporter les modifications de duniter 1.8.7 en 1.9.

@kimamila

ne peut-on pas débrancher les noeuds 1.9 tant que les tests complets n’ont pas été passé ? On est quand même sur une version de dev, et l’on boit que cela pose problème. Ginkgo en sera perturber, je ne sais bien, mais au moins on prend les choses dans l’ordre. La tout a été bricoler, avec Duniter 1.9 et pas entièrement tester…

Ca me semble compliqué, mais pas impossible, g1specte recense 10 instances en 1.9.0, il faudrait contacter chacun des admins et attendre qu’il accepte de stopper son instance (perso je fais tourner un noeud, il en reste plus que 9 :p). Autrement, est-ce qu’il serait possible de sortir une nouvelle version de cesium qui filtre les noeuds pour interagir uniquement avec les versions < 1.9 ? Cela permettrait de fixer les problèmes et tester à la fois en 1.8.7 et en 1.9-dev.

[Moul]

Quel nœud utilises-tu ? Il est surement désynchronisé.

Pour référence :

Duniter error "The transactions' sandbox is full" : Nœud désynchronisé

Bonjour, …

[jytou]

4Go de mémoire je suppose ? C’est peut-être un peu juste du coup. Personnellement, j’ai réussi à synchroniser en indiquant 10Go à node (mais 8 devrait probablement marcher aussi). Le truc, c’est qu’une fois synchro ça fonctionne sans avoir besoin d’autant. Peut-être devrions-nous songer à nous passer des répertoires déjà synchro, même si c’est très très moyen car il faut avoir confiance dans l’envoyeur.

[aya]

Pi utilise l’extension firefox de cesium en version 1.7.6. Au lancement, la sélection automatique du noeud a choisit le noeud g1v1.p2p.legal avec une piscine pleine et en retard de ~20k blocks.

[ness]

@aya

Au lancement, la sélection automatique du noeud a choisit le noeud g1v1.p2p.lega

tu dois avoir le mode expert enclenché du coup pas d’ analyse complete du réseau

@jytou

truc, c’est qu’une fois synchro ça fonctionne sans avoir besoin d’autant. Peut-être devrions-nous songer à nous passer des répertoires déjà synchro

où simplement ne pas syncro dans la ram …

[jytou]

@ness

où simplement ne pas syncro dans la ram …

Le problème c’est que si on ne le fait pas en ram, c’est très très lent actuellement, même avec un SSD…

[ness]

à 2oM/s sans ssd et sans fibre donc, telecharger 5Gigas prend 25oo secondes

[Damery]

@aya

g1v1.p2p.legal

Souvent, le noeud g1v1.p2p.legal ne donne rien de bon. Il faut fermer césium puis relancer pour qu’il choisisse un autre noeud qui est synchro.
C’est ce que j’ai expérimenté.
Je viens de tester à nouveau en forçant g1v1.p2p.legal et je n’ai plus d’opérations, dés que je remets g1.duniter.org, je retrouve mes opérations …

[tuxmain]

La synchro n’est pas qu’un téléchargement. L’application des blocs est coûteuse en lecture/écriture synchrone et non séquentielle de la bdd, ce qui est lent.

[ness]

@tuxmain là où ça nous limte c’est le telechargement de la data d’ un morceau en ram non ?

[kimamila]

@aya

A mon avis cela devrait pointer vers un noeud local en 1.8.7 hébergé dans le domaine duniter.org, ou sinon vers un noeud en 1.8.7 comme g1.e-is.pro.

Je ne suis pas certain de la configuration d’avant, mais je penses qu’il y avait un nœud de l’infra Duniter. Sans doute géré par Ansible. cc @moul @cgeek une idée ?

Finalement, j’ai trouvé un contournement pour la prochaine version (1.8.8) de Cesium : implémenter un cas spécial pour ce noeud, et l’exclure de la sélection du noeud au démarrage. Ainsi, il pourra toujours être utilisé par les vieux Cesium < 1.7 (en évitant l’étranglement).

En attendant cette version de Cesium, est-ce qu’on peut à minima le faire pointer vers des noeuds 1.8.7 ?

@aya

Ca me semble compliqué, mais pas impossible, g1specte recense 10 instances en 1.9.0, il faudrait contacter chacun des admins et attendre qu’il accepte de stopper son instance (perso je fais tourner un noeud, il en reste plus que 9 :p). Autrement, est-ce qu’il serait possible de sortir une nouvelle version de cesium qui filtre les noeuds pour interagir uniquement avec les versions < 1.9 ? Cela permettrait de fixer les problèmes et tester à la fois en 1.8.7 et en 1.9-dev.

Oui, en réalité c’est exactement ce que j’ai codé (avant de lire tous vos messages). C’est effectivement plus simple, mais cela fait N requêtes de plus au démarrage (appel de /node/summary sur chaque noeud).

J’ai donc ajouté à Cesium un filtrage pour exclure les noeuds 1.9.0.

IMPORTANT: Il faudra donc releaser la prochaine version 1.9.x de Duniter en 1.9.1 (et donc sauter la 1.9.0 - qui correspond à une beta)

@tuxmain

@kimamila

à vérifier si cela vient de là, mais a mon avis les transactions ne sont pas triées.

D’après ./gql/src/queries/txs_history.rs les transactions devraient être triées par numéro de bloc d’écriture :

Pouvez-vous tester autant que vous pouvez sur différents noeuds, et me redire sur quel noeuds les opérations sont mal triés ? en donnant le noeud, la version et sa config de storage (issu de /node/summary)

C’est peut-etre aussi les noeuds 1.8 qui n’archivent pas les TX ?

@aya

Pi utilise l’extension firefox de cesium en version 1.7.6. Au lancement, la sélection automatique du noeud a choisit le noeud g1v1.p2p.legal avec une piscine pleine et en retard de ~20k blocks.

Pour ce problème de piscines pleine, j’ai ajouté plusieurs trucs :

• Traduction de l’erreur en français
• Avant d’afficher l’erreur, Cesium tente de renvoyer la TX à 5 noeuds tirés au sort, à partir des noeuds synchro trouvé au démarrage; L’erreur ne s’affiche que la TX n’a été accepté par aucun noeud;
• La vue réseau de Cesium permet de voir l’état des piscines (en mode expert) :
  
  

Avec tout ca, je vais donc pouvoir sortir une version de Cesium 1.8.8, qui réglera la plupart des problème des utilisateurs.
Reste le fait que tous ne seront pas encore sur cette version… et surtout qu’il faudra bien la tester !