Bonjour,
Mon Jeedom 4.3 stable fonctionne parfaitement sous Docker mais depuis quelques semaines j’ai le % d’utilisation du processeur qui est important.
Et en regardant les processus qui tournent sur le NAS j’ai découvert que le processus ‹ ‹ mysqld › › occupait par moments 40 a 45% du processeur, puis revenait à 0. Peut etre toutes les minutes.
J’ai refait un Docker tout propre, tout mis à jour, et le probleme persiste.
Ta base de données semble être sollicitée.
Maintenant il faut voir dans Jeedom ce que tu fais.
Ou un plugin écrit / modifie bcp de données ou un truc que tu as mis en place, ou tu as bcp d’historisations, bref
Tu peux déjà tester pour voir si c’est un plugin spécifique, tu arrêtes les plugins un par un et tu monitores pour voir si y en a un qd tu l’arrêtes qui soulage un peu ce processus
J’ai tester en désactivant plugin par plugin : toujours le meme % du processus dans le Docker
J’ai meme désactiver tous les plugins : arreter tous les scénarios : meme probleme
Redémarrer mon Jeedom : meme probleme
Je suis sec…
ce probleme est récent depuis les dernières mises à jour Jeedom (en vu de la 4.4)
Bonjour,
Je ne sais pas répondre ! …
J’ai simplement installer Jeedom en Docker en utilisant l’image proposée par le paquet Docker, puis créer le Docker, modifier les ports, et ajouter les usb avec portainer
mais rien de particulier
Je ne sais pas pourquoi c’est externalisé
Lemars
oui tout a fait : c’est bien le processus du NAS (DS218+)
Et voici le courbe du processeur du NAS : c’est comme cyclique : y a un truc qui doit démarrer par moments et demande bcp de ressources (je suspecte une des dernières mises à jour des plugins : mais je ne sais pas laquelle)
Et j’ai fait un nouveau Docker : le 83 et j’ai mis tous les meme plugins : sans intégrer ma sauvegarde Jeedom : pas de scénarios, rien : le % du processeur est tres bas
J’ai regarder sur mon Docker 81 qui pose probleme : je n’ai pas de scénarios qui plantent ou tournent en rond, rien / j’ai supprimer plein d’historiques,
Rien ne me sautant aux yeux au vu des informations données, quelques points à considérer :
que la base de données utilise du temps CPU quand elle est sollicité n’a rien d’anormal. Tant que ça ne met pas la machine à genoux, il n’y a pas lieu de s’en préoccuper. Le processeur est là pour être utilisé, la RAM aussi. Tant que la machine n’est pas à 100% du processeur en permanence et tant que le kernel ne passe pas son temps à faire entrer et sortir des informations du SWAP, on est bon. De ce fait, en l’espèce, en quoi l’utilisation du temps processeur par la base de données est-il préoccupant dans ton cas ?
Si le temps d’occupation du processeur est préoccupant :
cette base de données, elle tourne sur quoi ? Dans le docker qui héberge Jeedom ou directement sur le NAS ? Au vu de la deuxième capture d’écran je dirais dans le docker qui héberge Jeedom, mais les réponses me font douter
une base de données, ça se configure en fonction de son usage. Il n’est pas impossible qu’elle manque de RAM pour telle ou telle fonction interne. Il faut en examiner les logs pour savoir quoi configurer ou si un programme est parti en saucisse et passe son temps à la solliciter pour rien
les disques du NAS peuvent être en cause. Quel est leur état de santé, leur taux d’occupation ?
le DS218+ n’a pas de disque SSD de cache. Si les disques à plateaux internes sont déjà un peu juste, leur capacité limite pour répondre aux demandes de lectures/écritures de la base de données peut être atteinte et ralentir cette dernière. D’où l’importance de configurer correctement ladite base de données pour qu’elle ait suffisamment de RAM et qu’elle l’utilise correctement pour répondre dans des temps acceptables.
En fait mon NAS tournait entre 10 et 15% de charge avec Jeedom / avec des pics à 30% il y à 3 mois
Et depuis c’est 30 à 60% avec longtemps à 50 / 60%
Et je n’ai pas fait de modifs importantes : quelques scénarios améliorés mais vraiment pas grand chose (ajout de 2 prises Lidl avec mesure de conso)
Au niveau mémoire j’avais ajouter 1 barrette mémoire et remplacer une à l’intérieur ou il fallait tout démonter : et le % de charge mémoire est largement bon. Au total 16Go. Copie ecran de l’utilisation
J’ai 2 disques (non SSD) et ils sont en raid et au total c’est 38% d’occupation sur 4To : ils datent comment le NAS de mars 2019. Ce sont des Western Digital Red 4Go Sata 6Gb/s. Le tout acheté neuf. Tout semble normal d’apres le NAS.
Mis a part Jeedom on a des photos (DS Photos) et films (Emby), et Download Station mais rien de plus : peu de sollicitations finalement. Pas de serveur web ou autre.
J’ai fait les quelques manip disponibles dans le menu reglage / systeme / config db : mais cela n’a rien changé
Comment puis je voir l’état ou la charge de la BDD ? ou optimiser sa config ?
Du côté du NAS, ça semble bon. En tout cas, rien ne me choque.
Pour ce qui est d’analyser le comportement de MySQL/MariaDB, cela peut se faire :
analysant les logs qui sont, sous Debian, situés dans /var/log/mysql/ Suivant les cas, il peut être nécessaire de modifier la configuration de la base de données pour loguer telle ou telle chose n’apparaissant pas dans les logs
en utilisant MySQLTuner qui se trouve dans le paquet mysqltuner sous Debian.
Dans ton cas, comme on est dans un docker, je ne sais pas. J’ai utilisé Docker à ses débuts, n’ai pas été convaincu et n’utilise plus que des VMs avec un OS complet. Donc à part te dire que le github de MySQLTuner est ici, je ne sais pas te dire comment l’installer (c’est un script perl, il te faut donc perl)
Pour commencer, je commencerais tout de même à fouiller du côté des logs de Jeedom. Si tes deux dockers ne diffèrent que par la restauration de ta sauvegarde, c’est là-dedans qu’est le problème.
Les prises Lidl, elles fonctionnent sous quel protocole ? Elles génèrent quoi comme lecture/écriture dans la base de données. Certains protocoles sont extrêmement bavards. Certains périphériques sont à la limite du spam quant à l’utilisation de leur réseau.
