RPI4: occupation mémoire augmente de jour en jour

Bonjour,

Le swap de 2Go ne bouge pas, il reste libre à 100%
Par contre la mémoire diminue de jour en jour.
Exemple ici, où il reste 802 Mo de libre alors que le RPI4 n’a plus été rebooté depuis 9 jours.

Je n’avais pas cela avec Debian Buster
Maintenant je suis en Debian Bullseye 11.9

Avez-vous aussi cela?
Y a t-il une solution?
Merci

Bonsoir.

Vous avez certainement un plugin qui fonctionne avec Python 3

Et nous sommes beaucoup à constater ce phénomène depuis le passage a Debian 11.

Dans mon cas, c’est le plugin RFXCOM qui créer cette consommation sans fin de la mémoire ram.

Dans un console ssh, lancez la commande : top

Et depuis Jeedom, redémarrez les plugins qui ont un daemon. Puis, contrôlez la taille de la mémoire en temps réel avec la commande top.

Vous allez pouvoir identifier le ou les plugins qui consomment cette mémoire.

Ne faites pas tout d’un coup, le but est d’identifier le problème. Commencez par RFXCOM.

Merci Fabrice
Effectivement j’utilise RFXCom. Je vais y regarder.
Si c’est lui le « coupable », une solution existe t-elle?
Merci

Salut,

Jusqu’à résolution du plugin, tu peux créer un scénario qui s’execute 1x par jour et ajouter un bloc code avec ceci:

	// id du plugin
	$_plugin_Id = 'Le_Nom_Du_Plugin';

	// charger le plugin 
	$_plugin = plugin::byId($_plugin_Id);
	if (is_object($_plugin)) {
	    	// start deamon ...
		$scenario->setLog('redémarrage du plugin ------->>> ' . $_plugin_Id);    
    		$_plugin->deamon_start(true);    
		
    }

Ceci devrait alors ‹ libérer › la mémoire consommée par son deamon depuis les 24 dernières heures.

1 « J'aime »

Salut @Fabrice ,

Je ne suis pas encore passé a Debian11 … seulement a Jeedom 4.4.6 sur Debian10. Et tout fonctionne bien.
Je vois des plugins comme JMQTT, Teleinfo ou encore worksLandroid qui utilisent Python3:

Est-ce que tous les plugins utilisant Python3 engendrent ce problème sous Debian11 ?

Bonjour.

Je ne serais pas te répondre de manière juste. Je connais le problème pour le plugin RFXCOM et encore, c’est pondéré par rapport au nombre de périphériques RFXCOM que le plugin gère.

J’ai lu sur le plugin Xiaomi qu’il y avait le même problème.

2 « J'aime »

Merci @Fabrice ,

Je pense attendre alors avant de migrer vers Debian11 …
J’ai eut tellement de soucis de ‹ fuite de mémoire › dans le passé (si on peut l’appeler comme ça) que je ne souhaite plus me frotter à ce type de problème aussi tôt.

Merci!

Sébastien

Bonjour,

Je ne suis pas sûr que ce soient les plugins qui soient en cause mais bien la version de Python 3
Il apparait clairement que la version 3.9.2 génère une fuite mémoire tandis que la 3.9.19 ne présente pas le souci.

Il y a donc une possibilité de repasser en version 3.9.19 afin de valider cette thèse et mettre hors de cause les plugins. Ce qui le cas échéant pourrait permettre à Jeedom et aux plugins de « bloquer la version »

Cordialement
Luis

1 « J'aime »

Hum, effectivement la c’est un peu galère …
C’est a l’équipe Jeedom de trouver une solution pour forcer l’installation de Python 3.9.19 alors non?
Je vais bien sagement rester sur Debian10 pour le moment.
On a constate le même problème chez un ami qui est passe sur Debian11 et on a mis un scenario en place pour redémarrer les deamons des plugins en en question.

Non
Je n’ai pas encore détecté le moindre problème avec worxlandroid par exemple :wink:

Incorrecte également.

Tous les codes tournant sous 3.9.2 ne génère par forcément une fuite mémoire.

C’est plus complexe que cela, probablement certaines (versions de) libs en combinaison avec certaines versions de python

Il est même possible par exemple qu’une lib ai un problème dans sa version x, qui est la seule dispo pour 3.9.2 et que dans la version x+1 le problème ait été réglé mais mis à dispo que pour une version python > 3.9.2
Dans ce cas la version de python serait complètement hors cause.

Il y a beaucoup trop de raccourci fait autour de cette histoire

Ok super mais bon cela ne résout pas le schmilblick hein :slight_smile:
Que faire en tant qu’utilisateurs de Jeedom?
On est d’accord qu’il y a des circonstances qui crées de l’instabilité en faisant les mises a jours, c’est alors aux développeurs des plugins d’en chercher les causes?
Pas simple cette histoire… je suis d’accord qu’il faut suivre l’évolution d’un système, rien que pour des questions de sécurité et de support mais migrer vers quelque chose qui peut causer des soucis a l’utilisateur n’est pas une bonne chose.
Ce que je vais faire c’est un backup de mon Jeedom et le migrer vers un Jeedom de test sous Debian 11 et tester le tout pendant un moment avant faire la mise a jour sur mon Jeedom de Prod… mais l’utilisateur lambda il fait quoi ?
Ton conseil @Mips serait de rester en Debian10 pour le moment? (je viens du monde MS Windows … mon expérience Linux est limite … :slight_smile: )

Merci,

Sébastien

J’ai fait un Top pour voir l’occupation mémoire
les plugins RFXCom, JMQTT n’apparaissent pas comme consommateurs de mémoires.
Python3 et le plugin deCONZ apparaissent continuellement.
deCONZ me semble normal car j’ai une douzaine de modules zigbee lié à la clef ConbeeII ça me semble donc logique qu’il utilise des ressources mémoire.

C’est qu’il faut regarder, c’est quel plugin libère de la mémoire quand vous l’arrêté.