Fuite de mémoire

[echo]

Bonjour

Il y a une semaine la mémoire était saturée voir copie ci-dessus. J’ai vidé la mémoire tampon avec la commande: sync; echo 3 > /proc/sys/vm/drop_caches
Vider le cache n’est pas recommandé si j’ai bien compris: perte des valeurs des virtuelle, etc…

Aujourd’hui, la mémoire occupée et la mémoire tampon est à un niveau élevé. Je suis sur un NUC intel I5 avec Proxmox.

Au vu des post sur Python 3, j’ai redémarré le plugin Jmqtt, détection téléphone et fail2ban la mémoire tampon n’a pas été libérée.

Mes plugins:

Redémarrer Jeedom tous les 3 jours est possible mais il faut tout vérifier après ou utiliser la commande citée plus haut.

Que me conseillez-vous, ça va péter dans les 3 jours à venir.

[ArnaudA]

Regarde ce qui bouffe ta mémoire :

@nebz

Il y a une commande dans la config jeedom > os/db (dernier onglet) > invité de commande (ou qqch du genre) > Colonne de gauche dans la liste des commandes

Ou htop en ssh et classer par mémoire pour du temps réel

et ensuite tu vois …

[echo]

Merci j’ai fait des relevés.

[xavax59]

salut, tu as des plug in qui utilisent python ?

[echo]

Bonjour

Avec les conseils de ArnaudA en faisant la comparaison de l’occupation mémoire j’ai repéré Jeedomconnect.

Avec un script pour surveiller JC toutes les 10 secondes :

root@jeedom:/home/jeedom/Efface/scripts# cat memjc.sh
#!/bin/bash
for (( ; ; ))
do
ps -eo size,pid,user,command | grep -e jeedomConnectd | awk ' { print $2 } ' >> memjc.dat
sleep 10

Le contenu de memjc.dat :

root@jeedom:/home/jeedom/Efface/scripts# cat memjc.dat
4095137
4095174
4095214
4095399
4095467
4095504
4095541
4095580
4095617
4095807
4095872
4095909
4095946
4095985
4096022
4096502
4096657
4096694
4096731
4096768
4096805
4097003
4097068
4097106
4097145
4097182
4097219
4097406
4097470
4097507
4097546
4097585
4097624
4097824
4097947
4097986
4098023

Delta par minute: 5504 - 5137 =367
Delta par heure: 367 x 60=22020
Delta par jour: 22020 x 24 = 528480

Sur 5 jours : 2642400

en plugin utilisant Python : JeedomConnect, Présence téléphone, jmqtt

Fail2ban.

[Mips]

je pense qu’il faut pas focus sur 10s
c’est tout à fait possible qu’un process augmente parfois puis rediminue

faut voir sur une journée;

exemple sur un de mes plugins, on voit bien qu’il y a des petites variations:

il n’y a eu aucun redémarrage du démon excepté le dernier drop ou ensuite je reste à 36 => c’est une mise à jour de la beta dans laquelle j’ai optimisé le démon

et cela tourne sur python 3.9.2 / debian 11

[echo]

Bonjour

Je ne pense pas que c’est lié à JeedomConnect l’augmentation est bien trop petite, mon calcul fait apparaître une augmentation de 2,6 Mo en gros pour 5 jours. Lorsque je lance la commande top je visualise une augmentation de la mémoire cache de plusieurs Méga par jours. Il faut que je creuse.

[echo]

Bonjour

J’ai avancé, j’ai désactivité au fur et à mesure, un par un les plugins, il reste Mqtt, Zigbee2mqtt et srcipt.

Lorsque j’ai désactivé WifilightV2 la mémoire à été libéré de 1,5Go.

J’ai réactivé WifilightV2, la mémoire utilisée n’est quasi pas remontée.

Je vais donc investigué sur WifilightV2. C’est un plugin que j’ai acquis il y a peu de temps.

1,5Go cela me parait beaucoup pour un seul plugin.

[bernardfr.caron]

peux-tu taguer wifilightV2 ?

[Mips]

@echo a fait un sujet dédié ici Libération mémoire sur arrêt du plugin

Edit après edit du post: @echo il faudrait fermer un des deux du coup