jojo Posté(e) le 4 mai Signaler Posté(e) le 4 mai j'ai créé un utilisateur backup dont le host est %, et ça fonctionne ! Du coup je vais regarder quels sont les privilèges min à donner. Merci de m'avoir remis sur la bonne piste
Kana-chan Posté(e) le 5 mai Signaler Posté(e) le 5 mai Je ne connais pas le script, mais il y a peut-être une résolution de l'adresse en nom. Il aurait fallu mettre l'IP local 127.0.0.1, pour que cela fonctionne avec root, je pense. 1
jojo Posté(e) le 5 mai Signaler Posté(e) le 5 mai je ne connais pas non plus le script (et étant donnée ma nullité dans le domaine, je ne pourrais pas l'interpréter). Ceci dit av l'IP locale que tu m'as donnée, ça fonctionne => Merci
Lazer Posté(e) le 5 mai Auteur Signaler Posté(e) le 5 mai (modifié) Le 03/05/2025 à 18:53, jojo a dit : Et comme je n'ai pas de "limite" de stockage j'ai modifié le fichier config.inc.php pour avoir un stockage détaillé sur une longue période : // Old data purge delay $db_interval_temperature = 200; //was 7 La question que je me pose : "les DB de MariaDB ne sont-elles pas mises en RAM du syno, ce qui expliquerait les plantages ?" Probablement, car ta table domocharts_temperature doit avoir une taille considérable. Essaye de revenir à une valeur plus raisonnable pour voir si ça stabilise l'usage de la RAM. Dans DSM tu as des outils de diagnostiques des ressources utilisées (CPU, RAM, Disk, etc). Essaye d'identifier le process qui utilise le plus de RAM, si c'est mysqld/mariadb tu auras ta confirmation. Modifié le 5 mai par Lazer
jojo Posté(e) le 5 mai Signaler Posté(e) le 5 mai Il y a 1 heure, Lazer a dit : une taille considérable en effet le dump de la DB domotique génère un sql de 1.5 GB (contre 17000KB pour Kodi) je garde bcp, comme ça je ne me pose pas de question avec Grafana (car je ne suis pas encore à faire des comparaisons par mois sur plusieurs années) Il y a 2 heures, Lazer a dit : DSM tu as des outils de diagnostiques j'ai activé dernièrement le log du Moniteur d'activité, et chaque diminution de la mémoire utilisée correspond à un redémarrage (que je viens programmer automatique 2 fois par semaine) MariaDB semble en effet le plus gourmand en mémoire malgré que 300MB me semble raisonnable sur un total de 4GB. Je ferai tes tests > 20/5, car je serai bientôt hors de la maison; mais je reste déçu des conséquences, surtout que c'est une base de données, donc conçue pour traiter un grand nombre de données
Lazer Posté(e) le 5 mai Auteur Signaler Posté(e) le 5 mai (modifié) il y a 57 minutes, jojo a dit : mais je reste déçu des conséquences, surtout que c'est une base de données, donc conçue pour traiter un grand nombre de données Bah non, pourquoi crois tu qu'en entreprise on monte des serveurs avec plusieurs To de RAM ? (oui je parle bien de plusieurs To de RAM, il n'y a pas d'erreur d'unité). Une base de données, c'est effectivement bien conçu pour gérer de grosses quantités de données, mais il faut mettre les ressources matérielles derrière. Ce n'est pas avec un NAS d'entrée de gamme et ses petits 4 Go de RAM que tu vas aller bien loin... (désolé hein, tu l'as surement payé très cher ton NAS en tant que particulier, mais ça reste de l'entrée de gamme, ça ne répond pas aux besoins des entreprises qui ont des quantités de données importantes à gérer) Et c'est justement pour cette raison, parce que nous n'avons pas de grosses machines à domicile (au début, certains faisaient tourner ça sur un Raspberry PI) que j'ai prévu ce système de purge des données au bout de X jours avec historisation dans des tables d'archivage par jour, et même par mois. Après si tu veux jouer à l'apprenti sorcier avec des rétentions énormes, forcément, ça te coute cher en ressources matérielles pour faire tourner le bouzin. C'est possible, il va juste falloir penser à passer à la catégorie supérieure de NAS. Ou alors architecturer la base de données complètement différemment. D'ailleurs... même le moteur ne va pas convenir. MySQL (MariaDB) c'est adapté aux petites bases de données. Au delà, il y a d'autres bases (Oracle c'est le plus connu, le plus scalable, le plus cher aussi....) Voir à ce sujet les optimisations réalisées par @yves.guern : Modifié le 5 mai par Lazer
yves.guern Posté(e) le 5 mai Signaler Posté(e) le 5 mai il y a 10 minutes, Lazer a dit : Voir à ce sujet les optimisations réalisées par @yves.guern : Yen a pas un de vous deux qui croit aux théories sur la Synchronicité par hasard? 1
jojo Posté(e) le 5 mai Signaler Posté(e) le 5 mai il y a 56 minutes, Lazer a dit : des serveurs avec plusieurs To de RAM la "nouvelle" techno c'est la totalité de la DB en RAM, mais une DB d'entreprise (SAP par exemple) n'a rien à voir avec ce qui est hébergeable sur nos synos. Et les grosses (pour nous) quantités de données que je stocke dans ma DB, c'est de la rigolade par rapport aux entreprises.
Lazer Posté(e) le 5 mai Auteur Signaler Posté(e) le 5 mai Évidemment... c'est marrant j'étais sûr que tu allais répondre ce que tu as répondu Mais mon propos c'est bien de dire que si tu as besoin de traiter de grosses quantité de données, il te faut plus de RAM (en plus du stockage), et toute proportion gardée, on est loin des To de RAM. Car entre 4 Go et 4 To, il y a de la marge.... Sur mon Syno virtualisé, il se trouve que j'ai également 4 Go de RAM, et ça me suffit largement... mais avec 7 jours de rétention ! Pour autant, grâce au mécanisme d'historisation dans les tables *_day, j'ai 10 ans d'historique, et ça fonctionne très bien ainsi, cette quantité de données est largement suffisante pour sortir toutes les statistiques que je veux, avec de bonnes performances, et sans plantage. Et j'ai même 14 ans d'historique pour la consommation électrique (en dehors de DomoCharts, ce sont des tables perso)
jojo Posté(e) le 5 mai Signaler Posté(e) le 5 mai ces échanges m'ont fait réfléchir sur l'architecture de ma DB. mais je ne sais pas encore quoi, car (par exemple) une température extérieure moyenne n'a aucun sens. Mais garder 200 jours de détail est aussi stupide. Je dirais qu'un mois (30j) serait un bon compromis. Et avec Grafana j'interroge les tables *_day pour des graphes sur un plus longue période.
Lazer Posté(e) le 5 mai Auteur Signaler Posté(e) le 5 mai Perso je n'ai pas plus d'utilité de la température exacte à J-8 qu'à J-30 ou encore J-200, raison pour laquelle j'ai trouvé raisonnable de mettre une expiration à 7 jours, mais c'est justement personnalisable facilement pour que chacun y trouve son compte. Dans les tables day, tu n'as pas que la moyenne, tu as aussi le mini et le maxi de chaque journée, ce qui est plus utile car ça permet de voire la variation quotidienne (ce qui a un impact important sur l'inertie de la maison, et donc permet de faire des corrélation entre la température et la consommation du chauffage par exemple). Avec Grafana, tu peux exploiter ces mini et maxi dans les tables _day, ce que ne permet pas les graphs de DomoCharts. En fait, dès le début de la création de DomoCharts, j'avais prévu de conserver plus de données que ce ne permettent d'afficher les graphs, en vue d'une exploitation future. Après, si tu as besoin de plus précis, regarde donc le QuickApp DomoCharts+ (le "plus" qui change tout) dont on parlait plus haut, car il permet de conserver l'historique à l'heure près, ça te conviendra peut être. 1
Messages recommandés