Bonjour
J ai le meme problème que toi je suis en 4.3.20
Par contre je n ai pas zwavejs
Moi les seul pluging en commun avec toi activé son son mqtt manager et weather
Donc si tu vois que c est ton zwavejs ca serai peut etre indirectement mqtt manager ?
Du nouveau sur tes investigations ? Merci
Bonjour à tous
J’attendais un peu avant de vous donner des news.
Avec zwaveJS hors service la mémoire est restée relativement stable. Quelques que écart entre 55% et 52% sur 3 jours. je n’ai pas pu tester plus longtemps sans zwave car il gère mon chauffage mon ECS et mon alarme. Donc j’avais bloqué sur mes 3 jours de présence.
Pas de monté du swap non plus. Test lancé sur 3 x 24h avec le test de @pommedapi
Lundi soir j’ai donc comme le proposai @jpty réarmé le zwave et refait les mêmes tests
Dans un premier temps j’ai eu de la charge Swap vu la méthode de @pommedapi
après vérification avec la méthode de @Bad j’ai vérifier si cela venait du plugin zwave .
Voila les images. Est ce une charge connexe a Zwave mes amis les spécialistes ?
Swap 08012024 18H44
Analyse de 124k
Ce soir je n’ai plus de charge swap et un total identique sans zwavjs d’activé de ce week end
Par contre j’ai une chute de mémoire vive impressionnante depuis sa remise en service.
J’avais redémarrer un odroid N2 pour repartir sur une bonne base. Donc environ 70% de mémoire dispo au redémarage. La ce soir je suis a 47%. Lors des tests de ce week end sans la zwavejs j’étais a 53% environ.
Je pense qu’il faut ettendre un peu.l Logiquement a mémoire va continué à diminuer et comme mon swapiness et réglé sur 30% il ne devrait pas tarder à utiliser le swap. Et donc on devrait confirmer la fuite mémoire de ZwaveJS via le tets de @pommedapi et @Bad
je suis à votre dispo si vous souhaitez me faire faire d’autres manip. sinon des que j’ai de l’info je reviens vers vous.
@FIESTA peu être que mqtt est aussi coupable. on fera les test après si tu veux.
A très vite les zamis
Merci à vous pour votre implication
JM
2 « J'aime »
Salut @Vandoule
ton poste ma donné envie d’invertir sur mon problème un peut identique au tiens
Et en regardant la consommation de de la mémoire de mon jeedom je me suis rendu compte que le plugin xiaomi home consommer énormément de mémoire qui ne fait que grimper petit a petit .
j ai donc redémarrer le démon de ce plugin et la miracle j ai récupère toute ma ram
j ai donc mie en place un scenario qui reboot le daemon tous les dimanche a 4H00
Je verrai si ca peut resoudre mon probleme
En tous cas merci de m’avoir donné l’envie d’avoir envie 
Bonjour à tous
un peu de news
Voila ou nous en sommes ca continu a baissé tt les jours un peu plus ce soir 44%
je commence à déclencher du swap
Anlyse globale ace la Methode @pommedapi
Puis détaillé avec la methode @Bad
Visiblement pas le trace de zwave
Je vais donc encore attendre le temps que le swap déclenche un peu plus en espérant le voir pointer le bout de son nez. Donc à suivre
@FIESTA
De rien et merci pour ton retour. C’est une bonne solution de dépannage en attendant un correctif.
Je suppose que tu as fait ta recherche avec la même méthode.
Si le reboot du demon de ton plugin redonne de la mémoire alors peut être cela fonctionne pour d’autre plugin. Et donc peu être aussi pour le zwavejs.
Peux tu nous faire profiter de ton scenario ou code qui pourrait en dépanner plus d’un.
Donc bonne soirée à ou et a suivre
JM
Je vais voir avec le temps si cela peut suffire
Pour le moment j ai juste créé un scénario qui redémarre le deamon
Mais d autre piste plus simpa "plugin-jeelink# "
Merci a @anon53349806
Il faut que je test
1 « J'aime »
Salut @FIESTA
Si c’est confirmé que c’est bien zwavejs pour moi cette solution me permetrai d’attendre le correctif.
Merci à toi
Oui, j’avais aussi eu le même problème avec xiaomihome. Du coup j’ai viré ce plugin (payant, sic!), et plus de problème de memory leak.
Concentrez-vous sur l’augmentation de la mémoire utilisée par les différents process. L’utilisation du swap par n’importe quel process n’est que la conséquence des process qui prennent trop de place.
Je n’ai qu’un robot aspirateur xiaomi, dont j’ai abandonné l’idée de le piloter via jeedom.
Le reste étant les capteurs zigbee xiaomi aqara, pour lesquels je passe par une passerelle zibgee.
Moi il me reste pas mal d ampoule
Il faudrait peut etre que je passe par wifilightv2 si le reboot du deamon ne résout pas le problème
Mais je ne connais pas ce plugin et si il et compatible avec mais ampoules yeelight et xiaomi
A quand du wifi natif dans jeedom
Bonjour à tous
un peu de news
la mémoire a descendu jusque 42% Bizarrement cette fois ci elle est remonté a 50% hier après midi.
Ce qui est étonnant c’est cette gestion mémoire. je ne comprend pas a quelle moment elle décide de se purger pour revenir a un état stable. Parfois on va jusqu’au plantage et parfois elle remonte.
voila l’image
J’ai donc réaliser quelques investigation avec la methode de @pommedapi
Le swap est bien déclenché cette fois
je n’ai pas l’impression que nous sommes avec de la charge zwavejs
un test mémoire méthode @bad
les analyses
total 0
lr-x------ 1 mysql mysql 64 Feb 14 2019 0 -> /dev/null
l-wx------ 1 mysql mysql 64 Feb 14 2019 1 -> '/var/log/mysql/error.log.1 (deleted)'
lrwx------ 1 mysql mysql 64 Feb 14 2019 10 -> /var/lib/mysql/ib_logfile0
lrwx------ 1 mysql mysql 64 Jan 7 22:15 100 -> /var/lib/mysql/jeedom/interactQuery.MYD
lrwx------ 1 mysql mysql 64 Jan 12 10:20 104 -> 'socket:[36772597]'
lrwx------ 1 mysql mysql 64 Feb 14 2019 11 -> /var/lib/mysql/ib_logfile1
lrwx------ 1 mysql mysql 64 Feb 14 2019 12 -> /var/lib/mysql/ibtmp1
lrwx------ 1 mysql mysql 64 Feb 14 2019 13 -> '/tmp/ibqLdISL (deleted)'
lrwx------ 1 mysql mysql 64 Feb 14 2019 14 -> /var/lib/mysql/jeedom/history.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 15 -> /var/lib/mysql/jeedom/cmd.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 16 -> /var/lib/mysql/jeedom/timeline.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 17 -> /var/lib/mysql/mysql/servers.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 18 -> /var/lib/mysql/tc.log
lrwx------ 1 mysql mysql 64 Feb 14 2019 19 -> /var/lib/mysql/mysql/servers.MYD
l-wx------ 1 mysql mysql 64 Feb 14 2019 2 -> '/var/log/mysql/error.log.1 (deleted)'
lrwx------ 1 mysql mysql 64 Feb 14 2019 20 -> 'socket:[17035]'
lrwx------ 1 mysql mysql 64 Feb 14 2019 21 -> 'socket:[17036]'
lrwx------ 1 mysql mysql 64 Feb 14 2019 22 -> /var/lib/mysql/mysql/user.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 23 -> /var/lib/mysql/mysql/user.MYD
lrwx------ 1 mysql mysql 64 Feb 14 2019 24 -> /var/lib/mysql/mysql/db.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 25 -> /var/lib/mysql/mysql/db.MYD
lrwx------ 1 mysql mysql 64 Feb 14 2019 26 -> /var/lib/mysql/mysql/host.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 27 -> /var/lib/mysql/mysql/host.MYD
lrwx------ 1 mysql mysql 64 Feb 14 2019 28 -> /var/lib/mysql/mysql/proxies_priv.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 29 -> /var/lib/mysql/mysql/proxies_priv.MYD
lrwx------ 1 mysql mysql 64 Feb 14 2019 3 -> /var/lib/mysql/aria_log_control
lrwx------ 1 mysql mysql 64 Feb 14 2019 30 -> /var/lib/mysql/mysql/roles_mapping.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 31 -> /var/lib/mysql/mysql/roles_mapping.MYD
lrwx------ 1 mysql mysql 64 Feb 14 2019 32 -> /var/lib/mysql/mysql/tables_priv.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 33 -> /var/lib/mysql/mysql/tables_priv.MYD
lrwx------ 1 mysql mysql 64 Feb 14 2019 34 -> /var/lib/mysql/mysql/columns_priv.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 35 -> /var/lib/mysql/mysql/columns_priv.MYD
lrwx------ 1 mysql mysql 64 Feb 14 2019 36 -> /var/lib/mysql/mysql/procs_priv.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 37 -> /var/lib/mysql/mysql/procs_priv.MYD
lrwx------ 1 mysql mysql 64 Feb 14 2019 38 -> /var/lib/mysql/mysql/event.MYI
lrwx------ 1 mysql mysql 64 Feb 14 2019 39 -> /var/lib/mysql/mysql/event.MYD
lr-x------ 1 mysql mysql 64 Feb 14 2019 4 -> /var/lib/mysql
lrwx------ 1 mysql mysql 64 Feb 14 2019 40 -> /var/lib/mysql/mysql/gtid_slave_pos.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 41 -> /var/lib/mysql/mysql/innodb_table_stats.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 42 -> /var/lib/mysql/mysql/innodb_index_stats.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 43 -> /var/lib/mysql/multi-master.info
lrwx------ 1 mysql mysql 64 Feb 14 2019 44 -> /var/lib/mysql/jeedom/calendar_event.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 45 -> /var/lib/mysql/jeedom/cron.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 46 -> /var/lib/mysql/jeedom/dataStore.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 47 -> /var/lib/mysql/jeedom/interactDef.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 48 -> /var/lib/mysql/jeedom/listener.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 49 -> /var/lib/mysql/jeedom/object.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 5 -> /var/lib/mysql/aria_log.00000001
lrwx------ 1 mysql mysql 64 Feb 14 2019 50 -> /var/lib/mysql/jeedom/plan.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 51 -> /var/lib/mysql/jeedom/plan3d.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 52 -> /var/lib/mysql/jeedom/plan3dHeader.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 53 -> /var/lib/mysql/jeedom/planHeader.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 54 -> /var/lib/mysql/jeedom/scenario.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 55 -> /var/lib/mysql/jeedom/scenarioElement.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 56 -> /var/lib/mysql/jeedom/scenarioExpression.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 57 -> /var/lib/mysql/jeedom/scenarioSubElement.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 58 -> /var/lib/mysql/jeedom/update.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 59 -> /var/lib/mysql/jeedom/user.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 6 -> /var/lib/mysql/ibdata1
lrwx------ 1 mysql mysql 64 Jan 10 05:00 60 -> /var/lib/mysql/jeedom/view.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 61 -> /var/lib/mysql/jeedom/viewData.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 62 -> /var/lib/mysql/jeedom/gsh_devices.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 63 -> /var/lib/mysql/jeedom/message.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 64 -> 'socket:[36792923]'
lrwx------ 1 mysql mysql 64 Feb 14 2019 65 -> 'socket:[33139142]'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 66 -> 'socket:[21526480]'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 67 -> /var/lib/mysql/jeedom/widgets.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 68 -> 'socket:[36772580]'
lrwx------ 1 mysql mysql 64 Jan 8 14:25 69 -> 'socket:[36876965]'
lrwx------ 1 mysql mysql 64 Feb 14 2019 7 -> '/tmp/ib8Hkp1C (deleted)'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 70 -> /var/lib/mysql/jeedom/interactQuery.MYI
lrwx------ 1 mysql mysql 64 Jan 10 05:00 71 -> /var/lib/mysql/jeedom/interactQuery.MYD
lrwx------ 1 mysql mysql 64 Jan 10 05:00 72 -> 'socket:[21553822]'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 73 -> 'socket:[21558615]'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 74 -> /var/lib/mysql/jeedom/conso_teleinfo.MYI
lrwx------ 1 mysql mysql 64 Jan 10 05:00 75 -> /var/lib/mysql/jeedom/conso_teleinfo.MYD
lrwx------ 1 mysql mysql 64 Jan 10 05:00 76 -> /var/lib/mysql/jeedom/eqLogic.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 77 -> /var/lib/mysql/jeedom/eqReal.ibd
lrwx------ 1 mysql mysql 64 Jan 12 14:10 78 -> 'socket:[36765616]'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 79 -> /var/lib/mysql/jeedom/jeemate_devices.ibd
lrwx------ 1 mysql mysql 64 Feb 14 2019 8 -> '/tmp/ibwlZLJ5 (deleted)'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 80 -> /var/lib/mysql/jeedom/config.ibd
lrwx------ 1 mysql mysql 64 Jan 11 11:29 81 -> 'socket:[38030689]'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 82 -> /var/lib/mysql/jeedom/viewZone.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 83 -> /var/lib/mysql/jeedom/historyArch.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 84 -> 'socket:[36951651]'
lrwx------ 1 mysql mysql 64 Jan 12 16:05 85 -> 'socket:[37008168]'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 86 -> /var/lib/mysql/jeedom/jeemate_phone.ibd
lrwx------ 1 mysql mysql 64 Jan 8 01:00 87 -> /var/lib/mysql/jeedom/mesVin.ibd
lrwx------ 1 mysql mysql 64 Jan 10 05:00 88 -> 'socket:[21529873]'
lrwx------ 1 mysql mysql 64 Jan 10 05:00 89 -> 'socket:[21529457]'
lrwx------ 1 mysql mysql 64 Feb 14 2019 9 -> '/tmp/ibCi9p47 (deleted)'
lrwx------ 1 mysql mysql 64 Jan 12 01:20 90 -> 'socket:[37955732]'
lrwx------ 1 mysql mysql 64 Jan 8 01:00 91 -> /var/lib/mysql/jeedom/note.ibd
lrwx------ 1 mysql mysql 64 Jan 12 14:25 92 -> 'socket:[36781362]'
lrwx------ 1 mysql mysql 64 Jan 13 03:48 94 -> 'socket:[38529124]'
lrwx------ 1 mysql mysql 64 Jan 7 22:15 99 -> /var/lib/mysql/jeedom/conso_teleinfo.MYD
root@odroid-buster64:~# sudo ls -l /proc/19942/fd
total 0
lr-x------ 1 root root 64 Jan 10 05:00 0 -> /dev/null
l-wx------ 1 root root 64 Jan 10 05:00 1 -> /var/www/html/log/zwavejsd
lr-x------ 1 root root 64 Jan 10 05:00 10 -> 'pipe:[5976206]'
l-wx------ 1 root root 64 Jan 10 05:00 11 -> 'pipe:[5976206]'
lrwx------ 1 root root 64 Jan 10 05:00 12 -> 'anon_inode:[eventfd]'
lrwx------ 1 root root 64 Jan 10 05:00 13 -> 'anon_inode:[eventpoll]'
lr-x------ 1 root root 64 Jan 10 05:00 14 -> 'pipe:[5974458]'
l-wx------ 1 root root 64 Jan 10 05:00 15 -> 'pipe:[5974458]'
lrwx------ 1 root root 64 Jan 10 05:00 16 -> 'anon_inode:[eventfd]'
lr-x------ 1 root root 64 Jan 10 05:00 17 -> /dev/urandom
lr-x------ 1 root root 64 Jan 10 05:00 18 -> anon_inode:inotify
lr-x------ 1 root root 64 Jan 10 05:00 19 -> /dev/null
l-wx------ 1 root root 64 Jan 10 05:00 2 -> /var/www/html/log/zwavejsd
lrwx------ 1 root root 64 Jan 10 05:00 20 -> 'socket:[5975203]'
lrwx------ 1 root root 64 Jan 10 05:00 21 -> 'socket:[5976312]'
lrwx------ 1 root root 64 Jan 10 05:00 22 -> /dev/ttyACM0
lrwx------ 1 root root 64 Jan 10 05:00 23 -> /var/www/html/plugins/zwavejs/data/store/e768272d.jsonl
lrwx------ 1 root root 64 Jan 10 05:00 24 -> /var/www/html/plugins/zwavejs/data/store/e768272d.values.jsonl
lrwx------ 1 root root 64 Jan 10 05:00 25 -> /var/www/html/plugins/zwavejs/data/store/e768272d.metadata.jsonl
lr-x------ 1 root root 64 Jan 10 05:00 27 -> /dev/urandom
lrwx------ 1 root root 64 Jan 10 05:00 3 -> 'anon_inode:[eventpoll]'
lr-x------ 1 root root 64 Jan 10 05:00 4 -> 'pipe:[5976204]'
l-wx------ 1 root root 64 Jan 10 05:00 5 -> 'pipe:[5976204]'
lr-x------ 1 root root 64 Jan 10 05:00 6 -> 'pipe:[5976205]'
l-wx------ 1 root root 64 Jan 10 05:00 7 -> 'pipe:[5976205]'
lrwx------ 1 root root 64 Jan 10 05:00 8 -> 'anon_inode:[eventfd]'
lrwx------ 1 root root 64 Jan 10 05:00 9 -> 'anon_inode:[eventpoll]'
root@odroid-buster64:~# sudo ls -l /proc/26867/fd
total 0
lr-x------ 1 root root 64 Jan 12 12:00 0 -> /dev/null
l-wx------ 1 root root 64 Jan 12 12:00 1 -> /var/www/html/log/ewejee_node
lr-x------ 1 root root 64 Jan 12 12:00 10 -> 'pipe:[33142030]'
l-wx------ 1 root root 64 Jan 12 12:00 11 -> 'pipe:[33142030]'
lrwx------ 1 root root 64 Jan 12 12:00 12 -> 'anon_inode:[eventfd]'
lrwx------ 1 root root 64 Jan 12 12:00 13 -> 'anon_inode:[eventpoll]'
lr-x------ 1 root root 64 Jan 12 12:00 14 -> 'pipe:[33136318]'
l-wx------ 1 root root 64 Jan 12 12:00 15 -> 'pipe:[33136318]'
lrwx------ 1 root root 64 Jan 12 12:00 16 -> 'anon_inode:[eventfd]'
lr-x------ 1 root root 64 Jan 12 12:00 17 -> /dev/null
lr-x------ 1 root root 64 Jan 12 12:01 18 -> /dev/urandom
lrwx------ 1 root root 64 Jan 12 12:01 19 -> 'socket:[33139285]'
l-wx------ 1 root root 64 Jan 12 12:00 2 -> /var/www/html/log/ewejee_node
lrwx------ 1 root root 64 Jan 12 12:01 20 -> 'socket:[33142897]'
lrwx------ 1 root root 64 Jan 12 12:00 3 -> 'anon_inode:[eventpoll]'
lr-x------ 1 root root 64 Jan 12 12:00 4 -> 'pipe:[33142028]'
l-wx------ 1 root root 64 Jan 12 12:00 5 -> 'pipe:[33142028]'
lr-x------ 1 root root 64 Jan 12 12:00 6 -> 'pipe:[33142029]'
l-wx------ 1 root root 64 Jan 12 12:00 7 -> 'pipe:[33142029]'
lrwx------ 1 root root 64 Jan 12 12:00 8 -> 'anon_inode:[eventfd]'
lrwx------ 1 root root 64 Jan 12 12:00 9 -> 'anon_inode:[eventpoll]'
Bref rien de concluant pour le moment
Cependant une chose est certaine c’est que depuis que j’ai réactivé zwavejs la mémoire dégringole tous les jours de 4% à 5%. Certes la mémoire se régénère parfois et évite le plantage mais ce n’est pas toujours le cas même avec un swapiness activé à 30%
Je suis donc contraint
Soit d’attendre plus longtemps si je veux déceler la charge zwavejs en espérant que la mémoire ne remonte pas une fois de plus avant d’avoir trouvé.
Soit de refaire un test avec zwave desactivé pour voir si la mémoire se stabilise comme la dernière fois.
Comme la mémoire et remonté à 47% et que je suis 3 jours chez moi je vais en profiter pour bloquer mes installations en marche forcé et désactiver le zawve pour analyser si la mémoire reste stable une nouvelle fois.
Je referai les tests de charge mémoire avec zwavejs à partir de lundi soir.
Donc à suivre messieurs et une d’info dans le week end
Merci a vous
A titre d’information
Une fois que j’aurai fini nos tests il faudra bien que je trouve une solution pour éviter le plantage avant qu’un correctif arrive un jour pour palier à cette fuite mémoire de zwavejs en cours de détection.
La relance du démon zwavejs semble donc, comme proposé plus haut dans ce post une des solutions.
Voila donc ce que j’ai testé ce matin et prévu de mettre en place tous les samedi matin à 7h00 dès que j’aurai fini nos investigations. Espérons que la mémoire retrouve, avec cela, sa tête.
Bonne journée à tous
JM
Tu as vu : CPU usage increase since update to 9.6.0 (docker) · Issue #3514 · zwave-js/zwave-js-ui · GitHub
Pour le redémarrage j ai installé jeelink et c est top
Bonjour,
Si on regarde le source de la fonction deamon_start, il y a au début un arrêt du daemon suivi de son lancement:
Votre scénario peut se résumer à :
C’est la même action dans la config du plugin:
@jpty top . 
c’est corrigé.
merci
@Bad j’ai regardé. Visiblement même souci. Par contre je ne suis pas assez calé pour faire des recherches approfondies. Jusqu’à maintenant j’ai avancé parce que j’ai mis en ouvre vos conseils via toutes le personnes dans ce post qui m’ont données la main.
Je vais suivre de prêt cette article gibut et voir si il y a des actions concrètes, mais comme le dit le dernier message du post en question il ne semble pas y avoir de quoi faire avancer le schmilblick si c’est dans la construction. A part attendre une mise à jour et contournée le problème en attendant.
Voila mon ami. Je suis à ton écoute bien sur
JM
Pour info
Depuis ce matin ou j’ai coupé ZwaveJS, la mémoire est remontée toute seule de 45% à 54%
Voila le détail suivant la méthode de @bad
top -b -n1 -o’%MEM’
root@odroid-buster64:~# top -b -n1 -o'%MEM'
top - 13:52:15 up 5 days, 15:41, 1 user, load average: 0.93, 0.93, 0.98
Tasks: 452 total, 1 running, 451 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.6 us, 4.1 sy, 0.0 ni, 94.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3713.3 total, 436.8 free, 1241.6 used, 2034.9 buff/cache
MiB Swap: 1024.0 total, 1023.2 free, 0.8 used. 2165.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3139 mysql 20 0 3738888 444804 17968 S 0.0 11.7 458:55.23 mysqld
26867 root 30 10 981404 136556 37616 S 0.0 3.6 0:16.98 node
10577 root 20 0 4860460 88112 38392 S 0.0 2.3 36:13.05 node
29277 www-data 20 0 2734760 77116 13900 S 0.0 2.0 95:08.40 python3
11251 root 20 0 1012560 70312 24040 S 0.0 1.8 1:50.65 python3
26913 root 30 10 717044 59812 36624 S 0.0 1.6 0:01.78 node
25413 www-data 20 0 235660 58820 32616 S 0.0 1.5 27:33.57 php
8657 www-data 20 0 1971244 53624 10104 S 0.0 1.4 47:22.66 python3
26932 www-data 20 0 232512 47256 27396 S 0.0 1.2 4:17.97 php
10211 root 20 0 630500 47060 34660 S 0.0 1.2 0:00.33 node
15471 www-data 20 0 299944 46868 33928 S 0.0 1.2 1:26.11 apache2
25390 www-data 20 0 221324 43576 31844 S 5.6 1.1 28:46.54 php
19135 www-data 20 0 224320 38316 26588 S 0.0 1.0 0:06.07 php
19038 www-data 20 0 222272 36848 27280 S 0.0 1.0 0:55.84 php
On revient dans une utilisation stable à mon gout
JM
Que faut-il privilégier comme code ?
- via le plugin
- via le core
1 « J'aime »