Fuite mémoire dans un daemon avec $Cmd->event() et virtuel

Depuis quelques versions de Jeedom (je ne sais plus laquelle) le daemon du plugin wifilightV2 subit une fuite de mémoire et pas chez tous les utilisateurs du plugin. Après plusieurs tentatives pour cerner le souci, voilà où j’en suis arrivé.
lors de l’appel à :

$Cmd->event()

et s’il y a un virtual qui utilise la donnée mise à jour, quelle que soit son utilisation, il y a une fuite mémoire d’une dizaine de ko, ce qui sur la journée monte à 300 000 ko

je suis encore en debian 10 et core 4.4.18 :

idem sur ma machine de test debian 12 et core 4.4.18 :

idem avec cette config:

pour arrêter la fuite mémoire, il suffit de désactiver le plugin virtual.

Je relance.
Je suis le seul à avoir ce souci ?
C’est corrigé dans une future version ?
Merci

t as regardé ce sujet

mon daemon n’est pas en python mais php et surtout c’est l’activation du plugin virtuel qui provoque la fuite.
J’ai passé pas mal de temps à faire ce diag et la fuite est en dehors du plugin.

Bonjour,

Même constat dans ma tentative de faire un daemon pour lire mon EcoCompteur toutes les 15 secondes.

Démarrage du daemon plugin virtual activé

[2025-05-12 14:39:55][DEBUG] : Memory_usage Start: 829456 End: 1321968 Conso: 492512
[2025-05-12 14:40:10][DEBUG] : Memory_usage Start: 1319704 End: 1369352 Conso: 49648
[2025-05-12 14:40:25][DEBUG] : Memory_usage Start: 1365064 End: 1401032 Conso: 35968
[2025-05-12 14:40:41][DEBUG] : Memory_usage Start: 1396744 End: 1430152 Conso: 33408
[2025-05-12 14:40:56][DEBUG] : Memory_usage Start: 1425864 End: 1471744 Conso: 45880
[2025-05-12 14:41:11][DEBUG] : Memory_usage Start: 1467456 End: 1537104 Conso: 69648
[2025-05-12 14:41:27][DEBUG] : Memory_usage Start: 1532816 End: 1578712 Conso: 45896

Désactivation du plugin virtual ou désactivation des virtuels avec des cmds renseignées par le daemon. Fin des fuites mémoire.

[2025-05-12 14:41:42][DEBUG] : Memory_usage Start: 1574424 End: 1578712 Conso: 4288
[2025-05-12 14:41:57][DEBUG] : Memory_usage Start: 1574424 End: 1578712 Conso: 4288
[2025-05-12 14:42:12][DEBUG] : Memory_usage Start: 1574424 End: 1578712 Conso: 4288
[2025-05-12 14:42:27][DEBUG] : Memory_usage Start: 1574424 End: 1578712 Conso: 4288
[2025-05-12 14:42:42][DEBUG] : Memory_usage Start: 1574424 End: 1578712 Conso: 4288
[2025-05-12 14:42:58][DEBUG] : Memory_usage Start: 1574424 End: 1578712 Conso: 4288
[2025-05-12 14:43:13][DEBUG] : Memory_usage Start: 1574424 End: 1578712 Conso: 4288

Ré-activation du plugin virtual


[2025-05-12 14:43:28][DEBUG] : Memory_usage Start: 1574424 End: 1624464 Conso: 50040
[2025-05-12 14:43:43][DEBUG] : Memory_usage Start: 1620176 End: 1653584 Conso: 33408
[2025-05-12 14:43:59][DEBUG] : Memory_usage Start: 1649296 End: 1678560 Conso: 29264
[2025-05-12 14:44:14][DEBUG] : Memory_usage Start: 1674272 End: 1707680 Conso: 33408
[2025-05-12 14:44:29][DEBUG] : Memory_usage Start: 1703392 End: 1749288 Conso: 45896
[2025-05-12 14:44:45][DEBUG] : Memory_usage Start: 1745000 End: 1786752 Conso: 41752
[2025-05-12 14:45:00][DEBUG] : Memory_usage Start: 1782464 End: 1840696 Conso: 58232
[2025-05-12 14:45:15][DEBUG] : Memory_usage Start: 1836408 End: 1878160 Conso: 41752
[2025-05-12 14:45:31][DEBUG] : Memory_usage Start: 1873872 End: 1903136 Conso: 29264

La fuite mémoire est d’environ 10k par commande renseignée.

La seule solution est-elle de faire un daemon en python ou en nodejs?

et ton code utilise le plugin virtuel?
je comprend pas grand chose à votre problème à la base: le simple fait d’activer le plugin virtuel provoque une fuite ou vous utilisez le plugin dans votre code?

perso des démons en php j’en ai aussi et le plugin virtuel est activé sur toutes mes installations et pas de problème

Les commandes renseignées par le daemon php sont « reprises/dupliquées » dans des virtuels.
Si elles ne sont pas reprises dans des équipements virtuels, il n’y a pas de fuite.

J’ai remplacé $cmd->event($value) par:

$jsonrpc->sendRequest('cmd::event', array('id' => $cmd->getId(), 'value' => $value));

Avec auparavant la création de $jsonrpc:

$jsonrpc = new jsonrpcClient('http://127.0.0.1/core/api/jeeApi.php', 'API_KEY_CORE');

et plus de fuite mémoire dans le daemon:

0050|[2025-05-12 16:59:06] DEBUG  : Memory_usage Start: 1068416 End: 1070400 Conso: 1984
0051|[2025-05-12 16:59:21] DEBUG  : Memory_usage Start: 1068416 End: 1070400 Conso: 1984
0052|[2025-05-12 16:59:37] DEBUG  : Memory_usage Start: 1068416 End: 1070400 Conso: 1984
0053|[2025-05-12 16:59:52] DEBUG  : Memory_usage Start: 1068416 End: 1070400 Conso: 1984
0054|[2025-05-12 17:00:09] DEBUG  : Memory_usage Start: 1068416 End: 1070400 Conso: 1984
0055|[2025-05-12 17:00:24] DEBUG  : Memory_usage Start: 1068416 End: 1070400 Conso: 1984

et votre démon il tourne comment?
je veux dire, certains ici (j’ai déjà vu ca), laisse une boucle sans fin pour coder leur démon et à priori gère un sleep dans leur boucle; c’est ca qui est fait? pcq alors la réponse est là

Non c’est:

$cron->setDeamonSleepTime(config::byKey('pollInterval', __CLASS__, 15));

J’ai suivi les consignes de cet autre fil où il y avait des fuites de mémoire d’un daemon PHP avec $cmd->event() ou checkAndUpdateCmd

De mon côté c’est avec un sleep (wifilightV2)

Salut,

Pour info depuis cette longue investigation faite l’an passé je n’ai pas résolu ce problème de fuite de mémoire depuis le démon php de mon plugin SMA.
Comme énoncé, le fait de redémarrer le démon automatiquement chaque jour corrige temporairement (à long terme :grin:) le soucis.
L’historique de la mémoire montre simplement des dents de scie où la perte de mémoire se creuse après redémarrage du démon puis revient à sa valeur initiale au moment du redémarrage du démon.

Et en fait, pourquoi vous utilisez des virtuels dans vos plugins? Pourquoi ne pas avoir directement une commande dans l’équipement ?

Et est-ce que le problème se produit avec un autre plugin que virtuel? En ayant un plugin bidon juste pour le test s’il faut

Hello,

A ce que j’ai compris, c’est le virtuel qui utilise les cmds du plugin, et non l’inverse.

c’est les virtuels qui utillisent le plugin.

Bonjour,

C’est ce que j’ai écrit au dessus:

Pb dans la propagation des valeurs des commandes du plugin vers les commandes du plugin virtuel ?

ok d’où ma question: