J’ai relayé sur le forum monnaie-libre :
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…
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.
@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.
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 ?
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 ?
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…
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.
Salut j’ai ce message d’erreur après la validation d’un virement dans l’extension cesium 1.7.6 dans Firefox :
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 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.
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.
Quel nœud utilises-tu ? Il est surement désynchronisé.
Pour référence :
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.
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.
tu dois avoir le mode expert enclenché du coup pas d’ analyse complete du réseau
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…
à 2oM/s sans ssd et sans fibre donc, telecharger 5Gigas prend 25oo secondes
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 …
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.
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 ?
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)
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 ?
Pour ce problème de piscines pleine, j’ai ajouté plusieurs trucs :
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 !
En effet c’est bien dans ansible et il y a bien un noeud local.
@Moul il suffirait de retirer les lignes 141 à 156 ?
