Causes possibles d'une saturation mémoire ?

[OJC]

Bonjour,

 

Ce matin, ma HC2 s'est retrouvée à empêcher des scènes (basiques) de se lancer en raison d'une saturation RAM, laquelle était de fait à 99 % dans le panneau de diagnostics. Reboot impossible, donc recovery et tout le bazar. Pas un problème, ça lui fait toujours du bien

 

Seulement voilà : comment identifier la cause d'une saturation RAM ?

 

Vu que j'ai bossé hier soir sur Heating Manager, je me doute bien que j'ai dû merdé quelque part en codant. Mais comment identifier le truc ? Qu'est-ce qui peut entraîner une saturation de la RAM comme ça ?

[Lazer]

Etrange, et pas facile à trouver l'origine.

 

Dans ces scripts VD, tu peux mesurer la consommation de mémoire du moteur LUA. Chercher des exemples, c'est Krikroff qui l'a implémenté dans ses modules virtuels, que j'ai repris et que je mets dans les miens aussi.

En affichant régulièrement la conso  mémoire dans la main loop, tu verras si celle-ci augmente indéfiniment ou pas.

[OJC]

On peut le faire dans une scène, aussi ?

[Lazer]

je ne sais pas, tu me diras s ça fonctionne

[OJC]

Bon, apparemment c'est collectgarbage("count"), mais j'arrive pas à voir si ça concerne uniquement le script en cours d'exécution ou si ça concerne tout ce que le moteur Lua est en train de faire tourner

 

@Krikroff ?

[OJC]

[DEBUG] 16:06:10: Heating Manager v. 2.1 (2017) by OJC
[DEBUG] 16:06:11: [MEMORY USAGE] Current function StartHeatingManager : 539.67 Mb
[DEBUG] 16:06:11: [MEMORY USAGE] Current function StartOverrideManager : 283.35 Mb
[DEBUG] 16:06:16: [MEMORY USAGE] Current function StartOverrideManager : 462.44 Mb
[DEBUG] 16:06:22: [MEMORY USAGE] Current function StartOverrideManager : 638.04 Mb
[DEBUG] 16:06:27: [MEMORY USAGE] Current function StartOverrideManager : 399.07 Mb
[DEBUG] 16:06:32: [MEMORY USAGE] Current function StartOverrideManager : 574.97 Mb
[DEBUG] 16:06:37: [MEMORY USAGE] Current function StartOverrideManager : 335.79 Mb
[DEBUG] 16:06:43: [MEMORY USAGE] Current function StartOverrideManager : 513.02 Mb
[DEBUG] 16:06:48: [MEMORY USAGE] Current function StartOverrideManager : 271.22 Mb
[DEBUG] 16:06:53: [MEMORY USAGE] Current function StartOverrideManager : 451.8 Mb
[DEBUG] 16:06:58: [MEMORY USAGE] Current function StartOverrideManager : 627.6 Mb
[DEBUG] 16:07:03: [MEMORY USAGE] Current function StartOverrideManager : 398.18 Mb
[DEBUG] 16:07:09: [MEMORY USAGE] Current function StartOverrideManager : 573.99 Mb

Parce que c'est quand même bizarre ce que ça me sort

 

[Lazer]

C'est que le script en cours, car chaque VD et chaque scène s'exécute dans un process différent au niveau de l'OS.

En fait, il y a autant de moteur LUA que de scènes et VD qui tournent.

 

Par contre, tes chiffres sont délirants !!! Moi je suis à quelques centaines de Ko au pire, jamais de Mo.

[OJC]

Oui, je trouve aussi... J'ai dû me planter sur l'unité de mesure... ça sort en bytes, c'est bien ça ?

 

EDIT = Bon, j'ai fait le boulet, ça sort en Kb...

Modifié le 18 novembre 2017 par OJC

[Lazer]

Tu m'obliges à faire du LUA un samedi après-midi, alors que j'étais tranquillement en train de faire des wipe dalvik-cache

 

Apparemment ce sont des ko :

 

fibaro:debug('<span style="color:gray;">Total memory in use by Lua: ' .. string.format("%.2f", collectgarbage("count")) .. ' KB</span>')

 

[OJC]

C'est ce que j'ai vu, merci pour la confirmation et désolé pour le Lua du samedi

 

En même temps, si tu traînes par ici...

[Lazer]

donc en fin de compte, tu as des valeurs qui ne sont pas aberrantes.

[OJC]

Oui, ça ce sont les chiffres après modifs.

 

Je me suis rendu compte que je faisais toute les quelques secondes une série de table.insert dans le cadre d'un appel de fonction sur setTimeout, sans réinitialiser la variable avant... Du coup, je pense que ça a dû jouer, même si je vois mal comment ça peut saturer la mémoire vu la quantité de données réduites en jeu En tout cas, là je reste stable entre 400 et 700 Ko.

[Lazer]

Si tu alloue trop vite la mémoire, le garbage collector n'a pas le temps de faire le ménage, donc la mémoire augmente.

Ensuite, tu tombes dans des limites système de mémoire maxi allouée par process ou de nombre maxi de fichiers ouverts par exemple, il y a un topic il y a 1 an ou 2, on avait réussi à faire planter un VD en moins de quelques secondes en ouvrant un trop grand nombre de connexions HTTP (= fichiers ouverts sous Linux)

[OJC]

J'ai vu qu'il y a  une commande pour force le garbage collector à effectuer son cycle.

Mais bon, j'ai juste ajouter une ligne en affectant nil à ma variable, et ça roule

[Steven]

Bravo ... votre post à fait sauter @pepite et il m'a demandé de rajouter du code dans GEA .. merci les gars 

 

Pour info, voici ce que j'ai sur mon GEA 6.x (en 4.140)

[DEBUG] 17:01:46: Mémoire utilisée : 2283.59 KB
[DEBUG] 17:01:46: Mémoire utilisée : 2283.59 KB
[DEBUG] 17:01:46: Mémoire utilisée : 1810.07 KB
[DEBUG] 17:01:46: Mémoire utilisée : 1619.52 KB
[DEBUG] 17:01:46: Mémoire utilisée : 1974.85 KB
[DEBUG] 17:01:46: Mémoire utilisée : 1075.86 KB
[DEBUG] 17:01:46: Mémoire utilisée : 2285.73 KB
[DEBUG] 17:01:46: Mémoire utilisée : 1076.38 KB
[DEBUG] 17:01:46: Mémoire utilisée : 2286.72 KB
[DEBUG] 17:01:46: Mémoire utilisée : 1911.08 KB

Les valeurs sont prises toutes les 30secs, on y voit un écart du simple au double ... ces valeurs vous semble-t-elle correcte au vu du script GEA et de mon environnement de production (une cinquantaine de règles). Perso, ce qui me plaît c'est qu'il n'y a pas d'augmentation linéaire.

 

 

 

[pepite]

chuuuuut....Fallait pas le dire ;-) @Steven

Mais c'est bien ce post là qui m'a donné l'éventuelle possibilité de le rajouter ;-) dans GEA V6, méa culpa ;-)

[Lazer]

Et bien, ça consomme pas mal GEA !!!

Après les variations ne me surprennent pas tant que ça, c'est le garbage collector qui doit faire son job en tâche de fond, quand il a le temps. D'où l'absence de linéarité.

 

Je suppose que @Krikroff maitrise tout cela.

[Krikroff]

Effectivement ça consomme pas mal GEA 

 

Après l'essentiel étant que le garbage collector est l'occasion de faire son Job ce qui me semble bien le cas ici, et puis c'est la prod de @Steven je ne suis pas inquiet .

 

Le HC2 encaisse sans problème de gros scripts, sur ma prod dans les 500 devices, en gros 200 nodes, dans les 50 scènes et beaucoup de VD, des interfaces dans tous les sens. Scènes et VD avec des codes lua de 1500 à 3000 lignes (obligé de compresser pour la sauvegarde dans le HC2 ) et la box est d'une stabilité exemplaire depuis des années ! En revanche sur ma box de dev avec pas grand chose dessus et bien étrangement comme j’expérimente parfois boum .

 

@Steven, les valeurs sont prises toutes les 30secs , euh... mais le temps sur le DEBUG est toujours le même ?

 

[Steven]

@Krikroff Normal, je les ai cumulées dans un tableau que j'écrit en une seule fois, d’où l'heure du debug 

 

Là, on parle d'un GEA beta, brut de coffre sans aucune optimisation et avec plus de 70 contrôles/actions qui ne seront probablement jamais utilisés.

 

J'optimiserais tout cela aisément avant la version définitive. Mais les chiffres me semblent rassurant pour l'instant.

[Krikroff]

@Steven je plussoie


Envoyé de mon iPhone en utilisant Tapatalk

[OJC]

En même temps, 2 MB de RAM, c'est pas la mort non plus...

[OJC]

Bonsoir,

 

Visiblement, j'ai un autre problème puisque la mémoire de mon HC2 a recommencé par partir en fly. Je crois que j'ai compris d'où vient le problème, mais elle part en fly si vite que j'ai une erreur 503 immédiatement après un reboot. Est-il possible de rebooter le HC2 en mode 'sans échec', c'est-à-dire sans démarrer les scènes en %%autostart ?

 

A défaut, un mp pour rooter le bouzin serait bienvenu histoire d'éviter un nouveau recovery...