OJC Posté(e) le 18 novembre 2017 Signaler Posté(e) le 18 novembre 2017 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 Posté(e) le 18 novembre 2017 Signaler Posté(e) le 18 novembre 2017 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 Posté(e) le 18 novembre 2017 Auteur Signaler Posté(e) le 18 novembre 2017 On peut le faire dans une scène, aussi ?
Lazer Posté(e) le 18 novembre 2017 Signaler Posté(e) le 18 novembre 2017 je ne sais pas, tu me diras s ça fonctionne
OJC Posté(e) le 18 novembre 2017 Auteur Signaler Posté(e) le 18 novembre 2017 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 Posté(e) le 18 novembre 2017 Auteur Signaler Posté(e) le 18 novembre 2017 [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 Posté(e) le 18 novembre 2017 Signaler Posté(e) le 18 novembre 2017 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 Posté(e) le 18 novembre 2017 Auteur Signaler Posté(e) le 18 novembre 2017 (modifié) 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 Posté(e) le 18 novembre 2017 Signaler Posté(e) le 18 novembre 2017 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>') 1
OJC Posté(e) le 18 novembre 2017 Auteur Signaler Posté(e) le 18 novembre 2017 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 Posté(e) le 18 novembre 2017 Signaler Posté(e) le 18 novembre 2017 donc en fin de compte, tu as des valeurs qui ne sont pas aberrantes.
OJC Posté(e) le 18 novembre 2017 Auteur Signaler Posté(e) le 18 novembre 2017 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 Posté(e) le 18 novembre 2017 Signaler Posté(e) le 18 novembre 2017 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 Posté(e) le 18 novembre 2017 Auteur Signaler Posté(e) le 18 novembre 2017 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 Posté(e) le 20 novembre 2017 Signaler Posté(e) le 20 novembre 2017 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 Posté(e) le 20 novembre 2017 Signaler Posté(e) le 20 novembre 2017 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 ;-) 1
Lazer Posté(e) le 20 novembre 2017 Signaler Posté(e) le 20 novembre 2017 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 Posté(e) le 20 novembre 2017 Signaler Posté(e) le 20 novembre 2017 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 ? 1
Steven Posté(e) le 20 novembre 2017 Signaler Posté(e) le 20 novembre 2017 @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. 2
Krikroff Posté(e) le 20 novembre 2017 Signaler Posté(e) le 20 novembre 2017 @Steven je plussoie Envoyé de mon iPhone en utilisant Tapatalk
OJC Posté(e) le 21 novembre 2017 Auteur Signaler Posté(e) le 21 novembre 2017 En même temps, 2 MB de RAM, c'est pas la mort non plus...
OJC Posté(e) le 23 novembre 2017 Auteur Signaler Posté(e) le 23 novembre 2017 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...
Messages recommandés