Il s’agit du paramètre remoteipv4, et c’est donc l’IP du proxy qui doit apparaître ici. Pas l’IP interne du serveur.
Non, on ne s’est pas compris. le BMAS généré automatiquement quand le remote port est à 443 est de la forme « BMAS < host > < ip public > 443 » ma question est qu’est ce qui est utilisé pour la connexion, l’ip ou l’host. Car mon reverse proxy utilise l’host pour savoir où rediriger ce qui arrive sur le port 443. Si tu te connecte sur mon ip port 443 sans préciser d’host tu n’arrives jamais sur duniter.
Ah oui en effet, même chose pour tous les reverse proxies. J’avoue ne pas saisir l’intérêt de cette redondance IP / host dans les endpoints. J’imagine que c’est le host qui est utilisé quand il est défini, sinon le pb aurait été remonté depuis longtemps. On ne doit pas être les seuls à utiliser un reverse proxy…
Quand tu es sur du https oui je pense aussi.
Je vais voir ce soir ce que ca donne. Mais bon, ça ne résous pas les problèmes de timeout à gauche a droite.
@Pini tu me prêtes ton nœud ? Je le rajoute dans mon monitoring de latence voir si c’est un problème que chez moi ou plus global
Oui, on peut jouer avec je pense. C’est un noeud non membre. Qu’est-ce que j’ai à faire de mon côté ?
C’est l’host qui est utilisé s’il est présent.
La présence de l’IP en plus ne sert effectivement à rien. Ha si les puristes pourraient dire que ça sert au cas où la résolution DNS échoue, m’enfin dans ce cas ça ne marchera pas mieux car ceux qui configurent un nom de domaine ont généralement un reverse proxy.
Voila donc un truc que je m’attellerai à supprimer dans les endpoint des nouvelles API (GVA et autres à venir).
1 Like
Rien, juste ton accord 
et l’host et je me débrouille.
Je laisserai pas longtemps style 1 jour
En plus on est sur du https 
Je t’ai rajouté : https://smokeping-duniter.lucho14.website/smokeping/?target=Duniter.pini.BMAS
Par certain qu’on voit grand chose comme on est derrière le proxy. Faudrait un BMA en direct
Merci Pini, chez toi ça à l’air tout bon .
Du coup j’ai continuer de fouiner, j’ai fait un script qui check duniter 2 fois par seconde et si pas de réponse ca me renvoi la dernière ligne de log de duniter.
A chaque fois c’est pendant le saving block :
2021-04-25 20:48:35.946 INFO check - test_duniter: duniter test in progress…
2021-04-25 20:48:36.948 INFO check - test_duniter: timeout !!!
2021-04-25 20:48:37.001 INFO check - read_duniter_log: [‘2021-04-25T20:48:35+00:00 - \x1b[36mdebug\x1b[39m: Saving blocks…\n’]
Ca dure environ 15s pendant lesquelles le nœud ne répond pas.
Test d’écriture sur le disque :
root@duniter:~# dd if=/dev/zero of=/tmp/output bs=8k count=100k; rm -f /tmp/output
102400+0 records in
102400+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 2.08924 s, 402 MB/s
La je ne sais plus quoi faire du coup… @elois une idée ?
1 Like
Ha, toi tu as un HDD 
C’est normal, nodejs est monothread, donc BMA qui est géré par la partie nodejs ne peut pas répondre quand Duniter est pris par d’autre traitement.
Si tu fais le test sur un nœud GVA tu ne verras pas d’indisponibilité (sauf à le saturer en requêtes avec une attaque DDOS), car GVA est géré par un pool de thread.
Je n’ai pas de telles lignes dans mes logs. J’imagine que c’est spécifique aux noeuds membres qui font du calcul de bloc ?
Quelle version faut-il utiliser pour avoir cette fonctionnalité ?
→ Bah non un ssd, 400 Mo/s en écriture 
→ Non tout le monde je pense, il faut passer les logs en debug minimum pour le voir.
→ Version en cours de dev
Du coup je dois m’inquiéter ? C’est un comportement normal ?
Mon problème ou je ne vois pas le réseau c’est lié ? https://duniter.lucho14.website:443/network/ws2p/heads
La version de développement sur la branche dev, (où tag dev de l’image docker).
La version de développement peu présenter des instabilités et doit être maj fréquemment, donc ça demande de surveiller son nœud de près.
De plus, entre deux commit le schéma de la DB peut changer, je ne fournis de script de migration qu’entre deux versions stables, donc en version de développement il faut refaire une sync complète de la blockchain assez souvent.
À ma connaissance il n’y a que @poka, et moi qui maintenons un noeud public sur la version de développement.
Alors tu manques de RAM ou ton serveur est déjà bien occupé par d’autres services ?
non je pense pas.
Non j’ai testé en désactivant ce qui prenait du CPU et niveau RAM :
root@duniter:~# free -h
total used free shared buff/cache available
Mem: 2.0Gi 431Mi 1.2Gi 2.0Mi 378Mi 1.6Gi
Swap: 2.5Gi 30Mi 2.5Gi
1.2Go de libre
Bon ya vraiment un soucis avec moi et/ou mon nœud …
C’est bien ce que je disais tu manques de RAM, je recommande d’avoir au minimun 4 Go.
En moyenne duniter consomme peu de ram, mais sur certains traitements il peut avoir un besoin important en ram pendant un cours instant.
Bah non globalement il marche. Tu sais Duniter est encore une POC avec plein de petits problèmes, ça vient pas de toi 
1 Like
Ok, passage a 4Go de RAM fait