Testeurs g1-test : nouvelle pré-release 1.6.17 à tester!

@cgeek est tu ok pour que l’on builde la 1.6.18 ?

Oui allons-y !

1 Like

Concernant mes problèmes avec G-test je continue mon retour d’expérience. C’est peut-être un hasard mais, pour moi, tout ça à commencé vers le moment où j’ai commencé à bricoler autour de ce que j’ai compris de ce post. :face_with_raised_eyebrow: Explorer la base de données de Duniter.
Je devais être sur la 1.6.14 sur g-test et je calculais des blocks .J’ai donc installé Sqliteman et copié collé la base de donnés sur le bureau et exploré un peu tout ça. Ensuite, en bon débutant apprentis sorcier, j’ai ouvert, avec sqliteman, la base de données directement dans .config/duniter pendant que Duniter tournait, histoire d’explorer la BD en temps réel :worried: . Je crois que c’est à partir là que je ne suis plus arrivé à calculer un block sur g-test malgré les versions suivantes et des retours à la 1.6.14 et 16.16. Hier j’ai tenté de revenir sur G1 et je calcule des blocks au bout d’une demi heure après l’nstall. Depuis hier, je suis de retour sur g-test en 1.6.18 je me suis synchro sur 89.89.2.134: 9333 mon nœud suit bien la branche majoritaire mais ne calcule pas de blocks (comme dab). Ce qui m’inquiète le plus c’est que j’ai toujours plus ou moins les mêmes erreurs dans les logs depuis une semaine.

pour info j’avais désinstallé Sqliteman avant d’aller sur G1

@Mententon_03 alors il ne faut JAMAIS faire ça, c’est très mal… Il ne te faut ouvrir manuellement la bdd duniter que lorsque duniter est a l’arrêt, si tu veut qu’il tourne en même temps il faut copier le fichier duniter.db puis ouvrir la copie (c’est comme ça que je fais).

En effet, en cas d’ouverture de la BDD de duniter alros qu’elle est utilisée par duniter tu risque une corruption de la bdd, et la le seul remède c’est un duniter reset data et une nouvelle sync de zéro !

2 Likes

Merci Elois, oui je l’ai “compris” après, par-contre, j’ai désinstallé et installé plusieurs fois différentes versions de duniter en coupant ma connexion internet ou en éteignant le pc et en supprimant .config/duniter.
J’ai d’ailleurs découvert que si j’exportais ce dossier de la corbeille vers le bureau il se retrouvait, en fait, à nouveau dans .config !!? mais un rien m’épate car je parts de loin et avance pas à pas.
Bon, ce soir, je vais tenter tout de même de refaire un duniter reset data

Pour suivi :

Continuons à observer, car une valeur de 740 Mo pour Duniter Server me laisse quand même un doute :slight_smile:

Perso pour mes 3 nœuds membres je suis à :

180 Mo pour un duniter server accesibles seulement par Tor redémarré hier
400 Mo pour mon duniter-server accessible en clair redémarré il y a 2 jours
725 Mo pour un duniter server accesibles seulement par Tor pas redémarré depuis ne semaine

D’accord, et de mon côté ça stagne pour g1. Dans le doute j’ai rajouté localement à mon installation un module de détection de fuite mémoire, pour le moment rien à signaler.

Pour ma part, je suis aussi à environ 400 Mo pour mon duniter-desktop en clair. Mon processus date aussi de 2 jours…

Duniter-dektop à 828.3Mo :
Capture%20d'%C3%A9cran%20de%202018-02-12%2023-43-42

Sur mon serveur j’ai :

  • powCluster G1 à ~110 Mo
  • powCluster GT à ~115 Mo
  • duniter_default à ~340 Mo
  • gt à ~185 Mo

Question idiote , comment démarrer un nouveau compte (futur membre) g1-test
depuis sakia ( j’ai pas réussi à sortir du réseau Ğ1 qui est prédéfinit à la création d’un compte ),
depuis Cesium ( j’ai mis g1-test.duniter.org dans les paramètres , et Cesium me met qu’il y a une erreur ).
A moins que ce soit via Duniter directement , dans ce cas je n’ai pas encore cherché.
Merci d’avance.

EDIT : Je mets ça ici http://www.duniter.fr/g1-test-blockchain-de-test/

Je suppose qu’il faut lancer Sakia avec cette commande:
sakia --currency g1-test

Sinon https://g1-test.duniter.fr/ est très pratique aussi.

2 Likes

Merci Jean_Ferreira

Pour info : j’ai démarré les recherches actives de fuite …

1 Like

J’ai identifié 2 fuites, puis testé un correctif depuis hier soir sur un noeud serveur. Je suis resté à 250Mo de consommation depuis les 13 dernières heures.

@elois, je t’invite à tester cette version sur la MR#1278.

2 Likes

Des livrables Linux sont disponibles ici : https://git.duniter.org/nodes/typescript/duniter/-/jobs/2322/artifacts/browse/work/bin/.

Effectivement sur le graphe de mémoire vive mensuel on voit clairement la fuite, chaque décrochage correspond pile a un jour un j’ai restart ce noeud duniter :

tmp1

Je viens d’installer ton correctif et de relancer, je vais suivre ça, réponse d’ici quelques jours :slight_smile:

2 Likes

As-tu des nouvelles ? Personnellement je suis inquiet, car même s’il y a amélioration avec mon dernier correctif je crois toujours observer une augmentation mémoire sur le long terme.

Alors sur le serveur ou je teste ton correctif, j’ai deux nœuds sur g1, un membre et 1 miroir : je les ai lancé tout les deux vendredi 16 vers 18h et je suis la maintenant a 233 Mo pour le miroir et 125 Mo pour le membre.
Quand a la conso mémoire globale de mon serveur elle augmente effectivement mais c’est tellement léger que ça peut être du a d’autres choses que Duniter, je ne suis donc pas encore en capacité de trancher :
tmp1

Pour information : le noeud miroir fait du ws2p public a un quota de 20 incoming et 5 outcoming. Le membre ne fait que du privé a quota 5 (car j’ai déjà un autre noeud membre qui fait du ws2p public sur une autre machine).

EDIT : j’avais inversé les deux conso mémoire, c’est bien mon noeud miroir qui consomme plus, ce qui est cohérent avec leur config ws2p respective :wink:

1 Like