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.
As tu vérifié la gestion des historisations/archives ? Est-ce que tu n’as pas des équipements qui enregistrent des données trop fréquemment ?
Quelle est la taille de ta sauvegarde ?
pour les historisations j’ai fait attention, normalement c’est ok
Ma sauvegarde fait 130 Mo avec 26 plugins
je vais regarder le lien : voici le résultats : je peux faire des lissage sur les valeurs edf et puissance pour minimiser la base verif.txt (7,0 Ko)
Un peu de surcharge: que j’ai limiter en diminuant les requetes du plugin script de 6 requêtes en XML : pour le relevés des compteurs EDF qui était exécuté toutes 1 minutes : j’ai passé à toutes les 10 miutes
Idem pour les virtuels ou au final de nombreux virtuels j’avais ajouter une auto actualisation toutes les minutes : car plusieurs fois pour juste des problèmes d’affichage, je croyais avoir des erreurs, mais au final j’ai tout supprimer et mon Jeedom respire
Le % du processeur du NAS est de 20 à 30% et le Docker environ 20%
Bref le NAS ne sature plus et plus de processus mysqld qui monte dans les tours !
