Duniter 1.2.5 | Fuite mémoire : la saga continue

Version corrective 1.2.5

Version mineure qui apporte un nouveau correctif contre une fuite mémoire. Mention spéciale pour @Beun qui a activement participé à débusquer cette fuite. Merci à lui :slight_smile:

A noter que je ne prendrai pas le risque de vous annoncer qu’il s’agissait de la dernière, je me suis déjà fait avoir sur la version précédente ! Toutefois, ce ne sera pas pire qu’en v1.2.4.

N’hésitez pas à me faire des retours sur la conso mémoire après quelques jours de tests !

Synchronisation

:white_check_mark: Pas besoin de resynchroniser.

Compatibilité

:white_check_mark: Compatible avec Ğ1.


Mettre à jour sa version

5 « J'aime »

Bonjour,

pour info :
toujours avec une debian 32 bits, il a fallu que je purge $HOME/.duniter pour installer la nouvelle version.
Sauf erreur de ma part les deux liens “mettre à jour sa version” in fine pointe sur le même document.
J’ai utilisé la commande : curl -kL https://raw.githubusercontent.com/duniter/duniter/master/install.sh | bash
et en ne purgeant pas $HOME/.duniter je restais en v1.2.4 et j’avais des erreurs de "node-pre-gyp ERR! "

Voilà. Donc purge de “$HOME/.duniter” et : ~$ duniter -V
1.2.5
Merci

D’accord, en effet il peut y avoir des conflits avec cette méthode. Je conseille plutôt l’installation en téléchargeant simplement le fichier .deb et en l’installant sur son système.

Malheureusement pas en 32 bits :blush:

@cgeek Bien, j’ai créé un petit cluster ES one node avec authentification. Si tu veux (ou si d’autres veulent) que je leur crée un compte pour tracer la consommation de leur instance duniter, c’est possible.

ça passe par l’utilisation d’un petit agent appelé metricbeat, je vous expliquerai la conf. En désactivant une sonde (process), on obtient des données peu intrusives. Je vous expliquerai tout ça si quelqu’un est intéressé.

1 « J'aime »

Explique toujours, on pourra juger ensuite.

Les données sont stockées dans le cluster ElasticSearch one node https://flamel.es.afola.ovh .

La visualisation des données se fait dans Kibana https://kibana.flamel.es.afola.ovh .

J’envoie un mot de passe à quiconque souhaite (les sites sont protégés vers une authentification http basic).

Quiconque ayant un compte peut voire toutes les données du cluster. Sachez le bien et prenez le en compte pour la suite !

Je propose l’utilisation d’un agent qui s’appelle metricbeat.
Son installation sur un serveur à architecture x86(_64) est détaillée ici :
https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-installation.html
Derrière il faut configurer le fichier de configuration /etc/metricbeat/metricbeat.yml

metricbeat.modules:
- module: system
  metricsets:
    - cpu
    - load
    - core
    - diskio
    - filesystem
    - fsstat
    - memory
    - network
  enabled: true
  period: 10s
  processes: ['.*']
tags: ["duniter", "monpseudo"]
fields:
  env: prod
output.elasticsearch:
  hosts: ["flamel.es.afola.ovh:443"]
  protocol: "https"
  username: "monpseudo"
  password: "monpassword"

en adaptant monpseudo et monpassword.
Puis pour le lancer systemctl start metricbeat

Pour ARM, il faut compiler soit-même. Je peux détailler si nécessaire, mais c’est un peu chiant à faire.
Comme je suis pas un monstre, je vous propose un build à moi ci-dessous :
https://framadrop.org/r/7A1gH8Muh0#vMEleVNMSqTnVMtAAqsWbj8JYcMC4N0CH6N4K9mJQUQ=
par contre il n’est pas packagé debian du coup par de fichier service ni rien.

Une fois téléchargé et détargzé il suffit d’entrer dans le dossier metricbeat, adapter le fichier de configuration metricbeat.yml puis lancer

metricbeat -c metricbeat.yml

On obtient quelque chose de ce genre :


https://kibana.flamel.es.afola.ovh/app/kibana#/dashboard/11c90e50-40ca-11e7-bdca-a3ca5e4546b0

2 « J'aime »

OK, j’ai commencé à envoyer mes stats sur ce serveur. Je continuerai le temps de vérifier qu’il n’y a pas de soucis particulier niveau mémoire.

1 « J'aime »

Voila pour moi. J’ai revue la forme des visualisations et du dashboard.

Malheureusement, en faisant l’installation hier de l’agent j’ai redémarré par erreur mon noeud duniter… #boulet

Voici le mien, pour les 12 dernières heures :

Bon il faut plutôt regarder à partir de midi, car avant j’ai joué avec mes nœuds et j’ai fini par tous les redémarrer.

Tu fais tourner combien de noeuds ? Parce que le niveau basal est élevé !

Trois, et il y a plein d’autres services aussi, c’est mon serveur Yunohost.

j’ai l’impression que c’est toujours pas finis :x (bon après c’est sur la même machine que mon instance mastodon donc faudrait confirmer)

Je confirme le même ressenti :

@cgeek Je suis au regret de vous annoncer la mort de mon bien aimé process cette nuit vers 5h du matin !

Bon donc le constat est fait, des volontaires pour identifier la cause ?

@florck, @d0p1 : il me semble que l’on devrait faire des tests autorisant 1 Go de RAM pour Duniter, pour ne pas s’arrêter sur des observations locales, mais essayer d’avoir une tendance longue.

Notamment car quand j’observe mon serveur qui pourtant fait tourner 3 nœuds, donc avec des effets potentiellement 3 fois plus sensibles que sur un serveur avec 1 seul nœud, voici ce que j’observe :

Certes, la quantité de RAM consommée a augmenté continuellement de 1.2 Go le 25 mai 12h00 à 2.0 Go le 28 mai à 8h00 soit une augmentation de 800 Mo globale, soit une moyenne de 266 Mo d’augmentation par nœud en presque 3 jours, ce qui semble correspondre à l’augmentation constatée par florck. Par contre, c’est assez éloigné des +700 Mo en 12 heures de d0p1.

Mais je vais tenter de voir un peu plus loin avant de réellement conclure à la fuite. Je devrais vite avoir des résultats.

Dès ce soir en rentrant, je remonte la ram de ma machine. Si tu veux émettre des infos dans un fichier à intervalle régulier et qu’on les inclus dans Elastic après tu me diras.

Fait !
@cgeek à noter : la deuxième fois c’est monté en flèche et a mourru très rapidement :

En vue large et avec la courbe cpu :

@cgeek Merci pour la mention spéciale :slight_smile:

1 « J'aime »