/tmp qui passe en full, bdd qui se vide, à chaque arrêt brutal. Plugin suivi-conso?

bipbip4149 · Septembre 21, 2020, 3:06

Salut à tous,

J’ai un problème avec mon Jeedom, et je soupçonne le plugin suivi conso. Pour l’instant j’ai pas de logs ni rien, car à chaque fois je fais un restore avant que tout se vautre, mais la prochaine fois j’essaierai d’extraire des choses. C’est surtout pour savoir si d’autres ont ce comportement.

Ca arrive à chaque fois que la VM avec mon Jeedom est coupé à l’arrache, genre une coupure de courant. Ca commence par le /tmp qui se rempli à fond, sans fichier dedans. Pour le vider : faire un restart du service mysql. Si je le fais pas, très vite mon Jeedom rame, et au bout d’un moment, ma base de donnés se vide

Mais genre, elle se vide vraiment, elle passe de 1.2Go à quelques mégas. Les premières données à dégager sont celles du plugins, mais une fois je n’avais pas vu le problème, ca a même été jusqu’à dégager mes scénarios et tout

Si je vide le /tmp avec le restart de mysql, le problème reviens quelques heures après, indéfiniment, jusqu’à ce que je fasse un restore avec un backup qui date d’avant l’arrêt brutal.

Et c’est systématique. Chaque coupure de courant, ça le fait. Par contre, si j’arrête ma VM proprement avec un shutdown, pas de soucis. J’ai l’impression que c’est le truc pour la synchro du plugin qui part en sucette. La preuve, ca a recommencé tout à l’heure, et j’arrivais plus à faire de synchro (j’avais une mauvaise données remontée dedans, avec une journée à plus de 1000€, j’avais un peu de temps, j’ai viré les mauvaises lignes de la table, fais une synchro, et rien, il corrigeait pas les valeurs de la semaine, du mois, etc).

Quelqu’un d’autre a déjà eu ce comportement ? Ou je suis encore le seul ?

bipbip4149 · Septembre 21, 2020, 3:48

Ca semble bien venir du plugin :

Logs mysql :

2020-09-21 13:57:08 107 [ERROR] mysqld: Table 'conso_teleinfo' is marked as crashed and should be repaired
2020-09-21 13:57:49 107 [ERROR] mysqld: Table 'conso_teleinfo' is marked as crashed and should be repaired
2020-09-21 13:58:48 865 [ERROR] mysqld: Table 'conso_teleinfo' is marked as crashed and should be repaired
2020-09-21 13:59:31 865 [ERROR] mysqld: Table 'conso_teleinfo' is marked as crashed and should be repaired

Puis :

2020-09-21 16:12:35 1238 [Warning] mysqld: Retry in 60 secs. Message reprinted in 600 secs
2020-09-21 16:14:07 3077 [ERROR] mysqld: Disk full (/tmp/#sql_443_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
2020-09-21 16:14:07 3077 [ERROR] mysqld: Disk full (/tmp/#sql_443_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
2020-09-21 16:14:07 3077 [ERROR] mysqld: Disk full (/tmp/#sql_443_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")

Et le total :

2020-09-21 14:12:18 975 [ERROR] mysqld: Table 'conso_teleinfo' is marked as crashed and should be repaired
2020-09-21 14:12:59 975 [ERROR] mysqld: Table 'conso_teleinfo' is marked as crashed and should be repaired
2020-09-21 16:02:50 2490 [ERROR] mysqld: Table 'conso_teleinfo' is marked as crashed and should be repaired
2020-09-21 16:03:32 2490 [ERROR] mysqld: Table 'conso_teleinfo' is marked as crashed and should be repaired
2020-09-21 16:11:42 3037 [ERROR] Got an error from thread_id=3037, /build/mariadb-10.3-V9JMsi/mariadb-10.3-10.3.23/storage/myisam/ha_myisam.cc:1049
2020-09-21 16:11:42 3037 [ERROR] MySQL thread id 1982, OS thread handle 140194989340416, query id 1159297 localhost jeedom Waiting for table level lock
select timestamp,rec_date,hchp*1,hchc*1,ptec,papp*1 as papp,inst1,rec_time,imax1,temp,id_equipement,
                                DATE_FORMAT(FROM_UNIXTIME(`timestamp`), "%d-%m-%Y %H:%i") as date  From conso_current WHERE rec_date = current_date()  AND id_equipement = 345 order by timestamp desc limit 1
2020-09-21 16:11:42 3037 [ERROR] MySQL thread id 1238, OS thread handle 140194980783872, query id 1158332 localhost jeedom Waiting for table level lock
REPLACE INTO conso_teleinfo (timestamp , rec_date, rec_time ,hchp,hchc,ptec,inst1,papp,imax1,id_equipement,temp) VALUES (1600697475,"2020-09-21","16:11:15",33388,865997,"HP",0,0,0,468,0)
2020-09-21 16:11:42 3037 [ERROR] MySQL thread id 3037, OS thread handle 140194781755136, query id 1153400 localhost jeedom Checking table
CHECK TABLE `conso_teleinfo`
2020-09-21 16:11:46 1238 [ERROR] mysqld: Table './jeedom/conso_teleinfo' is marked as crashed and should be repaired
2020-09-21 16:11:46 1238 [Warning] Checking table:   './jeedom/conso_teleinfo'
2020-09-21 16:11:46 1238 [Warning] Recovering table: './jeedom/conso_teleinfo'
2020-09-21 16:12:35 1238 [Warning] mysqld: Disk is full writing '/tmp/STRRVj8Y' (Errcode: 28 "No space left on device"). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)
2020-09-21 16:12:35 1238 [Warning] mysqld: Retry in 60 secs. Message reprinted in 600 secs
2020-09-21 16:14:07 3077 [ERROR] mysqld: Disk full (/tmp/#sql_443_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
2020-09-21 16:14:07 3077 [ERROR] mysqld: Disk full (/tmp/#sql_443_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
2020-09-21 16:14:07 3077 [ERROR] mysqld: Disk full (/tmp/#sql_443_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
2020-09-21 16:14:07 3077 [ERROR] mysqld: Disk full (/tmp/#sql_443_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")
2020-09-21 16:14:07 3077 [ERROR] mysqld: Disk full (/tmp/#sql_443_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")

En gros la table teleinfo crash, il essaie de la réparer et rempli le /tmp

Bison · Septembre 21, 2020, 4:32

En effet je confirme avec toi l’analyse des logs.

Je crois que le meilleur moyen serait de coller un onduleur sur ta machine Jeedom pour éviter les coupures de courant. Pour le moment on dirait que seule la table conso_teleinfo souffre mais un jour ça sera une autre table de Jeedom ou un fichier système de ta VM…

bipbip4149 · Septembre 21, 2020, 5:07

J’ai essayé d’augmenter la taille du /tmp, il était de 128Mo, je l’ai passé à 300. Comme il est monté en RAM je veux pas aller trop loin non plus. Avec un peu de chance il aura assez de place pour finir sa tambouille.

Mais c’est quand même curieux que systématiquement, c’est cette table qui tombe

Bison · Septembre 21, 2020, 5:55

En même temps si ça se trouve depuis longtemps elle est « marked as crashed » et elle n’est jamais réparée donc à chaque reboot de mysqld le problème se pose puisqu’il vérifie les tables au reboot ?

naboleo · Septembre 21, 2020, 6:04

Salut.

En complément, tu peux voir un peu ce qu’il y a dedans… 1.2Go c’est hors norme à mon avis

bipbip4149 · Septembre 21, 2020, 6:51

L’idée me plait bien, même si lors d’un reboot normal, y a pas de problème. Mais elle a peut etre un soucis quand même. Je suis pas un pro mysql mais je vais aller voir sur le net comment vérifier et corriger tout ca.

Merci pour ton idée

bipbip4149 · Septembre 21, 2020, 6:52

C’est le plugin conso, il stock tout, c’est un gouffre ^^

naboleo · Septembre 21, 2020, 6:55

Il faut finement gérer l’archivage… par que niveau perf, ça doit s’écrouler si tu n’as pas une VM un peu costaud

bipbip4149 · Septembre 21, 2020, 6:59

La VM s’en sors pas trop mal. En fait le plugin archive tout un tas de données (conso HP, HC, température extérieure, etc) chaque minute, depuis 4 ans

J’avais commencé a virer des trucs (genre virer quelques heures par jours), mais c’est à faire sans arrêt, et je perds quand meme des données

Bison · Septembre 21, 2020, 7:03

Je te conseil de télécharger adminer, c’est un outil qui se résume à un seul fichier PHP donc à copier quelque part sur ton Jeedom et à accéder via un navigateur.
Tu trouveras asser vite la fonction repair.
Toutefois il faudra le faire quand la table n’est pas trop grosse sinon tu auras le même soucis d’espace disque non suffisant pour faire le repair.

Je regarderai à l’occasion l’espace disques de cette table chez moi mais naboleo a peut-être bien raison. 1,2 Go c’est peut-être un peu beaucoup je sais plus.

bipbip4149 · Septembre 21, 2020, 7:06

Bon bah du coup

MariaDB [jeedom]> check table conso_teleinfo;
+-----------------------+-------+----------+----------+
| Table                 | Op    | Msg_type | Msg_text |
+-----------------------+-------+----------+----------+
| jeedom.conso_teleinfo | check | status   | OK       |
+-----------------------+-------+----------+----------+

naboleo · Septembre 21, 2020, 7:11

25 petits mega ici… Pas d’archivage des données inutiles, une profondeur d’historique limité quand j’ai besoin d’un peu d’info (genre délai depuis dernière valeur) et un archivage pour les données « importantes » (genre T°, conso electrique etc). C’est certain j’ai pas le plugin conso mais personnellement j’ai du mal à voir l’utilité de la conso instantanée du 11/07/2016 à 16h34… Une conso moyenne ou un cumul dans le journée du 11 ça me semble bien plus exploitable

bipbip4149 · Septembre 21, 2020, 7:15

En fait c’est pas que j’en ai l’utilité, c’est le plugin qui est fait comme ça. Toutes les nuits, il recalcule tout par rapport à cette base.

Donc si je vire des journées, elle ne seront plus comptées dans le cumul du mois, de l’année, de l’année d’avant (on peux comparer avec l’année d’avant), etc.

J’avais demandé aux dev de voir si y avait pas moyen de diminuer mais j’ai pas trop eu de réponse. Sans le plugin, ma base doit faire 150 Mo à tout casser (mon Jeedom date de 2014).

naboleo · Septembre 21, 2020, 7:18

Dommage que ça ne suivent pas coté dev

superbricolo · Septembre 21, 2020, 8:14

Il y a une fonction dans le plugin pour archiver les données de la table conso_teleinfo et supprimer ces données de la base.

Et pour info, la nuit, le plugin calcule la dernière journée et pas tout.
Et si tu vires des journées de conso_teleinfo, tes historiques mois, années ne seront pas impactés.

Donc je pense qu’il y a tout ce qui faut pour gérer le volume de tes données. Je te conseil vivement de faire le ménage. Si tu as besoin, je peux t’aider.

bipbip4149 · Septembre 21, 2020, 9:13

Salut,

Si j’archive les données, on est bien d’accord que je les verrai plus dans le plugin ?

Y a un truc que je pige pas, concernant la table téléinfo, c’est étrange, car quand j’ai une données incorrecte qui me flingue toutes mes données (jour, semaine, mois année), c’est dans cette table que je vais la supprimer, et après une synchro manuelle de tout, ca me remet bien partout. Donc je me dis que si je vire tout, ca fera la même.

Et la nuit j’ai bien les 2 crons qui tourne pour le plugin : UpdateTable toutes les haures pour la journée, et le UpdateOldDay tous les jours à 0h30 pour les autres jours.

Du coup je suis perdu

Tout cela m’intéresse beaucoup, par contre, ca explique pas pourquoi cette table se vautre systématiquement quand y a une coupure de jus. SI ca arrive, j’ai 2h pour réagir avant que ma BDD commence à se vider, si je suis au travail, c’est des heures de galère a la clé ^^

superbricolo · Septembre 21, 2020, 10:13

UpdateTable mets à jour conso_jour toutes les 3h pour les données du jour.
UpdateOldDay met à jour à 0h30 les données du jour précédent dans conso_jour.

Et effectivement si tu archives et supprimes les données de conso_teleinfo tu ne les verras plus dans le plugin. Tu ne pourras plus remonter sur les années/mois précédents pour uniquement le graphe consommation du jour.

Toutefois si un jour tu as besoin, tu peux toujours réimporter tes données.

Mais tous les autres graphes et historiques sont basés sur conso_jour qui est d’un volume beaucoup moins important. Donc tu conserves ton historique. C’est pour cela que les imports externes se font dans conso_jour sans jamais renseigner conso_teleinfo.

Il faut bien comprendre que conso_jour est la synthèse de conso_teleinfo. Et que cela n’a pas d’intérêt de conserver les données à un intervalle de quelques minutes pour un historique à l’année.

Et par contre il ne faut jamais vider partiellement conso_téléinfo pour une journée, parce que dans ce cas tu fausses la synthèse de la journée dans conso_jour. Tant qu’il reste des données dans conso_teleinfo sur une journée, conso_jour sera mis à jour avec les données restantes. Donc le ménage se fait par journée entière. C’est pour cela que tu perdais des données quand tu faisais ton ménage partiel.

Après pour ton problème provient peut-être que la base de données veut se réparer et qu’ensuite ton disque est plein. Un restore de base de données passe par l’écriture des données dans des fichiers temporaires avec ensuite effacement des tables pour être ensuite réparé. Si tu n’as pas assez d’espace, il n’arrive pas aller jusqu’au bout. De plus avec un tel volume d’information, le restore ne prend pas 5 minutes.

Conclusion, fais du ménage. Après je conseille vivement de mettre un petit onduleur, car de toute manière les coupures intempestives des bases de données, ce n’est jamais très bon pour la base, ni pour le disque, et tu risques de perdre des données

bipbip4149 · Septembre 22, 2020, 6:20

OK c’est beaucoup plus clair merci beaucoup.

En effet, le graph de la journée ne me sers que pour la journée, j’en ai pas besoin pour les autres jours, et je ne les consulte jamais, donc inutile.

Encore une petite question : pour vider la table conso_teleinfo, je le fais à la main, ou c’est l’outil du plugin où il y a marqué « vider les données de plus de * mois » ? Histoire que je vide pas la conso_jour aussi ^^.

Merci

EDIT : je viens de voir que tu as déjà répondu juste au dessus, je tente ^^.

Merci encore

Bison · Septembre 23, 2020, 5:30

J’ai regardé chez moi comme prévu, 338 Mo pour 2,8 millions de lignes dans la table tele_conso