Gestion de la mémoire RAM Jeedom (afin d'identifier le besoin réel)

Heliospeed · Août 28, 2024, 3:56

Suite du sujet Gestion de la mémoire RAM Jeedom :

Bonjour,
Je relance ce sujet un peu volontairement car j’ai plus ou moins la même problématique et les intervenant avait l’air de maitriser ce sujet.

Je suis en recherche pour optimiser la RAM de mon Jeedom, car j’avais 2/2.5GB d’affectée à ma VM sous Proxmox et je voyais depuis quelques temps le swap se remplir.
Dans un premier temps j’ai augmenté mon swap de 1GB à 2GB mais je me suis vite dis c’est une mauvaise idée le SSD ne vas pas aimer ça.
J’avais modifié les montages tmpfs dans /etc/fstab en espérant libérer un peu de RAM.

Du coup, j’ai rajouter de la RAM sur mon serveur et j’ai alloué 4GB pour Jeedom et je me retrouve avec ce type de graph dans Proxmox :

Lorsque je reboot, la RAM descend, la pointe a été à 3.66GB d’après Proxmox.

Comme ma machine recommençait a swapper légèrement, j’ai changé le Swapiness de 10 à 5% en espérant que ça sera suffisant. De mémoire les process qui utilisait le swap avant mon reboot était mariaDb et apache.
Pourtant dans Jeedom je n’ai pas vu la RAM en dessous de 36% donc pour identifier la cause c’est un peu compliqué.

J’ai l’impression que si j’augmente la RAM je ne suis pas sur que cela soit vraiment suffisant. J’aimerai identifier le process en cause de cette surconsommation que je n’avais pas avant.

J’ai redémarré donc la commande free -m n’est pas parlante pour voir la consommation du swap.

$free -m

$free -m
               total       utilisé      libre     partagé tamp/cache   disponible
Mem:            3919        1302        1725          98         891        2271
Partition d'échange:       2023           0        2023

$df -h

$df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               1,9G       0  1,9G   0% /dev
tmpfs              196M    860K  196M   1% /run
/dev/sda1           14G     11G  2,9G  79% /
tmpfs              1,6G       0  1,6G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              256M     15M  242M   6% /tmp/jeedom
tmpfs              392M    8,0K  392M   1% /run/user/1000

J’avais rien de spécial dans les répertoires tmp (monté sur le tmpfs). J’avais déjà modifié un peu pour réduire l’utilisation de la RAM.

J’essaye d’identifié s’il n’y a pas de fuite mémoire sur des process (mis à part xiaomihome que je relance dès qu’il dépasse 200MB) le reste a l’air stable.

$ps -eo size,pid,user,command --sort -size

$ps -eo size,pid,user,command --sort -size
 SIZE     PID USER     COMMAND
529216    625 mysql    /usr/sbin/mariadbd
207144   2493 www-data homebridge
183108   2902 root     /usr/bin/node --preserve-symlinks server/bin/www.js
174668   6019 root     node index.js
158840   2763 www-data /var/www/html/plugins/ttscast/core/class/../../resources/venv/bin/python3 /var/www/html/plugins/ttscast/resources/ttscastd/ttscastd.py --logl
148744   2604 www-data homebridge-config-ui-x
129728   2879 root     node /usr/local/bin/yarn start
125532   2570 root     /usr/bin/node /var/www/html/plugins/mqtt2/resources/mqtt2d/mqtt2d.js --loglevel warning --socketport 55035 --mqtt_server mqtts://127.0.0.1:88
114928   2037 www-data node /var/www/html/plugins/alexaapi/resources/alexaapi.js http://192.168.1.22 amazon.fr alexa.amazon.fr ********* 1000
109688    492 root     /usr/bin/python3 /usr/bin/fail2ban-server -xf start
105548   2597 root     /usr/bin/node /var/www/html/plugins/philipsHue/resources/philipsHued/philipsHued.js --loglevel warning --socketport 55090 --callback http://1
102832   2685 www-data node /var/www/html/plugins/rflink/resources/rflink.js http://127.0.0.1:80/plugins/rflink/core/api/rflink.php?apikey=**********
91324    2818 www-data /usr/bin/python3 /var/www/html/plugins/xiaomihome/resources/xiaomihomed/xiaomihomed.py --loglevel warning --socketport 55019 --callback http:
89376    5990 root     npm start
87576    2341 root     node /var/www/html/plugins/gsh/core/class/../../resources/gshd/gshd.js --udp_discovery_port 3311 --udp_discovery_packet 4A_______6D --pid /t
85416    2278 www-data /usr/bin/python3 /var/www/html/plugins/eufy/resources/eufyd/eufyd.py --loglevel warning --socketport 60600 --callback http://127.0.0.1:80/plu
51188    5795 www-data /var/www/html/plugins/kroomba/core/class/../../resources/venv/bin/python3 /var/www/html/plugins/kroomba/resources/kroomba/kroombad.py --logle
34664     495 root     /usr/sbin/ModemManager
31556     464 root     /opt/TheengsGateway/bin/python3 -m TheengsGateway
29596     199 root     /lib/systemd/systemd-journald
26044     403 root     /sbin/dhclient -4 -v -i -pf /run/dhclient.ens18.pid -lf /var/lib/dhcp/dhclient.ens18.leases -I -df /var/lib/dhcp/dhclient6.ens18.leases ens18
25772     471 root     /usr/libexec/polkitd --no-debug
25576    2542 www-data /var/www/html/plugins/MQTTDiscovery/core/class/../../resources/venv/bin/python3 /var/www/html/plugins/MQTTDiscovery/resources/mqttdiscoveryd.
22912  121253 jeedom   (sd-pam)

MariaDb est consommateur de ressource, il conseille de sur leur site de passer la valeur swappiness à 1 (mais comme le serveur héberge Jeedom, j’ai préféré mettre 5 dans un premier temps)

Que me conseillez-vous ? J’ajouterai bien 512MB de RAM en plus mais j’ai l’impression que ça ne va pas résoudre mon problème de swap (Et j’aimerai bien comprendre le pourquoi du comment ).
Je n’ai pas vu la RAM descendre en dessous de 35% dans la page santé (ce qui m’aurait permis d’identifier un process ou autre).

A force de lire des articles un peu partout, on déconseille de mettre du swap avec un SSD (avant comme ça ne bougeait pas je ne m’inquiétait pas plus que ça).
Mais je me dis si je désactive le swap, la machine ne risque t’elle pas de cracher ? Idéalement j’aimerai revenir a une situation ou le swap est présent mais n’est pas utilisé, mais j’ai besoin d’identifier la RAM nécessaire par rapport à mon installation.

Merci pour vos retours.

Fabrice · Août 28, 2024, 7:35

Bonsoir.

Sur Debian 11 appliquez ce qui est indiqué ici à la lettre.

Après un redémarrage, je ne constate plus les problèmes que vous évoquez ici.

Heliospeed · Août 29, 2024, 5:56

Merci Fabrice pour ce partage. De mon côté, j’avais déjà appliqué ce paramétrage lors de l’installation de Debian 11.

sudo du -sh /var/log/* | sort -h | tail

$sudo du -sh /var/log/* | sort -h | tail
888K	/var/log/kern.log.1
1,1M	/var/log/syslog
1,6M	/var/log/auth.log.3.gz
1,7M	/var/log/auth.log.2.gz
1,7M	/var/log/auth.log.4.gz
2,9M	/var/log/syslog.1
14M	/var/log/installer
25M	/var/log/auth.log
39M	/var/log/auth.log.1
201M	/var/log/journal

Dans /etc/systemd/journald.conf j’avais mis les paramètres suivant :

[Journal]
SystemMaxUse=200M
RuntimeMaxUse=200M
MaxRetentionSec=1w

Lorsque je regarde plus en détail dans Proxmox la RAM est repassé à fait un bond de presque 1GB entre 1h et 1h30

Je ne sais pas si c’est une coïncidence mais j’ai le backup de Jeedom qui arrive pendant ce créneau.

Mips · Août 29, 2024, 6:23

donc à mon avis la db a eu besoin de ram, il y avait de la ram dispo donc elle l’a prise. the end.

Madcow · Août 29, 2024, 6:24

Bonjour,

Sous Linux si j’ai bien compris il faut garder en tête concernant la gestion mémoire :

elle n’est libérée qu’en cas de besoin. Donc par exemple celle utilisée pour le backup ne sera pas libérée après ce backup.
l’os va utiliser le maximum de mémoire disponible. Bien entendu si pas assez de mémoire le swap va baisser.

A noter que sous Debian 11 il y a des fuites mémoires avec certains plugins utilisant python (ce n’est pas de la faute de Jeedom ni des plugins).

Heliospeed · Août 29, 2024, 6:44

Mariadb a Augmenté de 100MB pendant ce créneau.
Ce matin je constate que la partition d’échange a été utilisé ±1Mo

free -mht

$free -mht
               total       utilisé      libre     partagé tamp/cache   disponible
Mem:           3,8Gi       1,5Gi       422Mi        83Mi       1,9Gi       2,0Gi
Partition d'échange:      2,0Gi       1,0Mi       2,0Gi
Total:         5,8Gi       1,5Gi       2,4Gi

Cela vient des process apache2 d’après les infos présente dans les fichiers /proc/{processId}/status
J’ai pour le moment VmSwap: 752 kB.

Y a t’il un custom a ajouter pour apache afin d’éviter de swapper lorsque la RAM est toujours dispo ?

Je vais mettre 1GB de plus en Balloning dans Proxmox en espérant résoudre ce problème définitivement…
Je vais aussi redescendre la partition de swap à 1GB comme à l’origine.

Mips · Août 29, 2024, 6:46

j’ai dit la db mais tu peux remplacer par autre chose

« xxx a eu besoin de ram … »

Heliospeed · Août 29, 2024, 6:46

Oui j’ai hâte de pouvoir passer en Debian 12 mais j’utilise encore des plugins qui ne sont pas encore compatible.

Heliospeed · Août 29, 2024, 6:52

Je suis d’accord avec toi, mais ce qui m’ennuis c’est que je ne vois pas le moment ou il manquait de la RAM sur ma VM pour que l’application swap.
D’après Proxmox le max d’utilisé était à ±90% du coup j’imaginai qu’avec le swapiness à 5, ça n’aurais pas du swapper à ce moment la…

Je vais mettre 1GB de plus de RAM ça devrait résoudre le pb .

Mips · Août 29, 2024, 7:04

ni de python donc personne ne bouge

Heliospeed · Août 29, 2024, 9:07

j’ai repassé le swapiness à 10%, normalement tant que je dépasse pas 4,5GB ça ne devrais pas swapper… Il ne me reste plus qu’à attendre.

Heliospeed · Août 30, 2024, 7:22

Finalement ça swap toujours un peu 256k avec apache… Je viens remettre le swapiness à 5% et croiser les doigts.

Heliospeed · Août 30, 2024, 12:02

Finalement ça swap toujours un peu 28k par process apache.
Est-il possible de dire à apache de ne pas utiliser le swap ? Pourtant je n’ai pas eu de pic identifier dans Proxmox (max 4.45/5GB depuis mon passage à 5%).

Je vais tenter de passer avec la valeur vm.swapiness = 0, je le configure pas encore en dur au cas ou j’ai un dépassement mémoire (qui ne serait pas vu par Proxmox).

lperenna · Août 30, 2024, 12:57

Bonjour,

Quel est le but ?
Interférer avec la gestion de ram de Linux.

Je ne comprends pas trop.

Si on dit config minimum 4Go de ram, pourquoi derrière surtout avec Linux essayer de jouer le sorcier ?

Heliospeed · Août 30, 2024, 1:22

Bonjour,

Le but au départ était de préserver mon ssd. A la base 2,5GB de RAM suffisait à Jeedom et je n’utilisais pas de swap. Du jour au lendemain (ou plutôt x mois après + installation de plugins) j’ai constaté que ma partition de 1GB de swap était bien utilisée (presque 100%). Avec les vacances j’ai fais pas mal de chose et pas eu trop le temps de faire de suivre ce qu’il se passait (hors application des mises à jours Debian)

La j’ai voulu trouver une solution (augmenter le swap (mais temporairement car c’est un SSD) j’ai commandé de la RAM.
Et je me suis mis en objectif de trouver la quantité de RAM nécessaire pour faire tourné mon Jeedom sans avoir besoin de swap et sans allouer trop de RAM.
J’ai doublé la RAM mais je constate toujours que ça swap alors que je n’atteins pas les 5GB.

J’imagine aussi que si le système privilégie la RAM j’aurais de meilleurs temps de réponses (même si avec un SSD ça se ressent moins)…

L’idée est de trouver la bonne quantité de RAM pour que l’OS utilise le swap vraiment en dernier recours par rapport à mon installation actuelle et avoir les meilleures perf.

Comme je ne comprend pas le swap d’apache par rapport au paramètre de swapiness que j’avais appliqué. Je m’attendais a avoir du swap si la RAM dispo n’était que de 256MB mais d’après l’état Proxmox la VM avait encore plus de 512MB dispo.

Il y a certainement un élément que je n’ai pas encore identifié d’ou mes interrogations.

Fabrice · Août 30, 2024, 5:08

Bonsoir.

J’avais exactement les mêmes que tu décris. Et tout a état solutionné avec deux actions ci dessous :
La mise à jour du plugin RFXCOM avec le deamonjeedom de Mips
Et la configuration que j’ai cité en 1er de jpty .

Et j’avais tout testé comme toi, jusqu’au Swap à 0 (pas de swap) mais Jeedom était vraiment lent dans cette configuration.

zztop · Août 30, 2024, 5:16

Bonjour @Fabrice , je n’ai pas compris (je dois avoir le cerf volant) :
La mise à jour du plugin RFXCOM avec le deamonjeedom de Mips
Par avance merci

Fabrice · Août 30, 2024, 8:23

Bonsoir.

En gros, avoir l’ensemble de vos plugins à jour.

zztop · Septembre 1, 2024, 5:21

Ok, merci pour la réponse
mais pas toujours facile sur une smart en debian 10…

Heliospeed · Septembre 2, 2024, 9:01

Bonjour,
Après moi j’ai tous mes plugins à jours, je n’ai pas le plugin RFXCOM, c’est compliqué d’identifier ce qui pose problème.
Je n’ai pas ressenti de ralentissement avec le swappiness à 0 pour le moment (je pense le passer à 1 pour voir si ça swap puis augmenter progressivement jusqu’à 3 ou 4)
Après mon plus gros consommateur c’est mariaDb avec 869 MB sachant que ma base pèse un peu moins de 131MB.