Très peu de noeuds calculant sur gtest/ bug d’exclusion

Je lance les build arm et windows, rendez-vous dans 1h ou 2. :slight_smile:

1 Like

Le build arm est livré. Par conte je n’arrive pas à faire fonctionner la build windows… bizarre car je n’ai rien touché depuis la dernière build… à suivre…

Edit: visiblement un problème de disque SATA. Grrr le stockage me joue des tours ces derniers temps, après la carte SD du raspi…

1 Like

Version Windows livrée.

1 Like

@cgeek
Oups error, avec une fresh install v1.6.25 synchronisation depuis g1-test.duniter.nanocryk.fr 443

`Progress:

Download: [||||||||||||||||||||] 100 %
Apply: [| ] 8 %

Status: GOT chunck #169/768 from 42250 to 42499 on peer 88.174.120.187:10904/usr/bin/duniter: line 15: 956 Killed $NODE “$DUNITER_DIR/bin/duniter” “$@”`

Bon je ne sais pas trop comment vous faites ça d’habitude …

  • Suppression du dossier .config/duniter dans mon home
  • Upgrade de 1.6.23 à 1.6.25
  • En cours de synchro c’est beaucoup plus lent à partir de 73%

ras sinon pour le moment

@isawien45, tu t’es synchronisé sur quel adresse ?
Merci

g1-test.duniter.fr

Le processus a été tué par le système, je ne peux pas te dire pourquoi. Néanmoins ça ne t’était pas arrivé avant, ce n’est pas la modification que j’ai apporté qui a provoqué cet arrêt.

Sur le réseau GT oui, il y a un palier ralenti à 73%, je n’ai pas regardé pourquoi. Un surcroît d’activité au niveau des transactions je présume.

Bon maintenant c’est lancé. Le calcul de bloc est en cours ( pas un seul de trouver pour l’instant -> Waiting for better proof conditions)

Un début de piste j’atteins la valeur limite de ma mémoire vive…
je continue l’inspection

En revenant à une fresh install sur une 1.6.23, même problème même niveau, c’était bien la consommation de mémoire vive qui vient juste passer le 1G vers 7-8% et fait sauter mon container. Problème qui est venu avec l’accroissement des données dan la blockchain

J’ai suivi la consommation de mémoire:

  • progression constante pendant le Download → ~900mo
  • pique autour des 7-10%
  • petite décroissance ensuite pour se stabiliser ~900mo

Voilà, donc j’ai monté le container à 2go pour la synchro et ça passe nickel

Par contre, j’ai essayé une synchro sur g1-test.duniter.fr, port 443 et 10900 & no way ?

Bonne journée à tous :wink:

1 Like

Ah oui ça c’est fort probable, la synchro rapide n’optimise pas du tout la consommation mémoire afin d’aller au plus simple.

Essaye avec l’extension .org plutôt.

1 Like

Merci pour l’info, j’ai passé ma synchro sur g1-test.duniter.nanocryk.fr 443

:+1:

1 Like

J’ai aussi constaté l’augmentation de l’utilisation mémoire, qui va d’ailleurs finir par poser un problème sur les raspberry où on ne peut pas étendre la mémoire…

Bon, je voulais m’excuser, depuis quelque jours, je n’ai pas pu générer de g1-test ( problème d’internet principalement) .
Je vais essayer de me rattraper, je regarde du coté d’un serveur kimsuffi ( j’hésite entre le ks7 et ks11) ( je voulais depuis un moment commencer ma dégafamisation, et il faut que je regarde encore du côté kvm et config docker en fonction des services que je vais installer).
Je trouve ce projet très intéressant donc ça sera sûrement un des premier soft installer ( en tous as pour la partie g1-test. Pour ce qui est de g1, il faut déjà que je rencontre des personnes, ça va être déjà plus compliquer …)

C’est pour bientôt.

@cgeek
Bon je ne sais pas si c’est un bug ou un fork. Sur cesium g1-test.duniter.fr, j’apparait en head ?

Alors que sur le client ça n’a pas l’air d’être le cas.

Je n’avais prévu de laisser tourner ce pc cette nuit. Le plus simple / mieux pour aider, est il préférable que je l’éteigne ou que je laisse en l’état et qu’il continu comme ça ?

Tu peux éteindre ton nœud, il semble avoir forké.

Nœud éteins.

Comment fait on pour revenir sur la bonne branche ?

En faisant une synchro sur un noeud à jour. Cela devrait suffire.