et redémarrer.
la base est toujours aussi grosse !
15 min âpres sans rien faire (+aucun plugin activé)
Cela vous parait normal ?
Il y a une technique pour la « nettoyer » ?
(évidement : Réglage >> System >>Configuraion >> _OS/DB >> Nettoyage de la base de données. Ne fait rien…)
Dec 23 23:29:31 localhost systemd[1]: Started Rotate log files.
Dec 23 23:29:31 localhost systemd[1]: apt-daily-upgrade.service: Succeeded.
Dec 23 23:29:31 localhost systemd[1]: Started Daily apt upgrade and clean activities.
Dec 23 23:29:31 localhost systemd[1]: phpsessionclean.service: Succeeded.
Dec 23 23:29:31 localhost systemd[1]: Started Clean php session files.
Dec 23 23:30:00 localhost systemd[1]: Started LSB: Set the CPU Frequency Scaling governor to "ondemand".
Dec 23 23:30:00 localhost systemd[1]: Reached target Multi-User System.
Dec 23 23:30:00 localhost systemd[1]: Reached target Graphical Interface.
Dec 23 23:30:00 localhost systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dec 23 23:30:00 localhost systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Dec 23 23:30:00 localhost systemd[1]: Started Update UTMP about System Runlevel Changes.
Dec 23 23:30:00 localhost systemd[1]: Startup finished in 16.989s (kernel) + 1min 4.603s (userspace) = 1min 21.593s.
Dec 23 23:31:08 localhost systemd-udevd[1518]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Dec 23 23:39:02 localhost systemd[1]: Starting Clean php session files...
Dec 23 23:39:02 localhost systemd[1]: phpsessionclean.service: Succeeded.
Dec 23 23:39:02 localhost systemd[1]: Started Clean php session files.
Dec 23 23:43:56 localhost systemd[1]: Starting Cleanup of Temporary Directories...
Dec 23 23:43:56 localhost systemd-tmpfiles[3172]: [/usr/lib/tmpfiles.d/fail2ban-tmpfiles.conf:1] Line references path below legacy directory /var/run/, updating /var/run/fail2ban → /run/fail2ban; please update the tmpfiles.d/ drop-in file accordingly.
Dec 23 23:43:56 localhost systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Dec 23 23:43:56 localhost systemd[1]: Started Cleanup of Temporary Directories.
Sauf si tu as des pb de place sur ton Jeedom, la taille du fichier qui supporte la bas de données n’a pas d’importance.
Il faut savoir qu’un fichier de base de données ne peut pas diminuer (simplement) de taille. Quoi qu’il arrive, il continuera de grossir et si tu supprimes des données, il restera à la même taille.
Par contre, le backup de ta base, lui, dépend du volume de données (export des données), pas de la taille des fichiers, d’où un petit backup.
Mais cette taillendu fichier historyArch N’A AUCUN IMPACT sur les perfs ou la mémoire jeedom
Si tu souhaites réduire le fichier, tu peux essayer une restauration d’une save de jeedom (je ne sais pas si il supprime la base avant de la restaurer), ou faire des manip MySQL, mais réservé aux experts…
Bonjour,
Où voyez-vous cette taille de 2.6Go ?
J’ai la même valeur sur ma Smart:
Quelle est l’unité de la colonne SIZE ?
En lisant le man, c’est des ko. Donc bien ~2.6 Go.
C’est la taille du process en mémoire. Ça ne me choque pas comparé à tout ce qui s’y ajoute:
Malgré l’optimisation des tables history et historyArch(4M rows), la taille du process en mémoire ne varie pas.
merci beaucoup pour cette précision.
Je m’amuserai à faire cela quand j’aurai mis mon jeedom sur VM (Presque bientot), car curieux de savoir qui prend autant.
si tu as la même chose, c’est surement que c’est « normal ».
Merci pour ton retour.
juste pour info :
comme vous dans la taille des bases.
Je suis pas certain mais je pensais que c’était également des ko (quand je fais la somme des bases + historique + backup, ça colle : je tombe presque sur le total de mémoire utilisée)
je trouve que ta base est gigantesque en effet, j’ai comparé avec mon jeedom de prod qui a plus de 5 ans d’ancienneté et réinstallé il y a plus de 2 ans sur buster. mes stats sont incomparables… notamment tes eqlogics, c’est énorme, tu as des tonnes d’équipements ou alors tu as créé et effacé des tonnes d’objets. L’historique est également énorme, tu dois collecter bcp de stats, bien plus que moi où je choisis bien les stats à historiser et je prends le temps de choisir également la période d’historisation.
en complément (edit) : pour bien connaitre mysql (j’ai construit un nombre de backends pro importants avec), le seul moyen de compacter le fichier c’est de repartir sur une base vierge et de restaurer un backup sql fait à la main avec le client en ligne de commande. Si tu n’est pas pro du sujet laisse tomber, de toute façon comme tu n’as pas des milliers de transactions par seconde sur ton serveur, ça ne changera rien à la perf. une autre solution c’est de réinstaller un backup de jeedom complet sur une version installée à zéro, le fichier de sauvegarde réinjectera les données mysql actives.
Je trouve la comparaison très pertinente… et pour continuer sur cette image, il faut imaginer que lorsque le réservoir est plein, le réservoir va grossir , mais ne diminuera jamais …
Du coup, il suffit d’1 fois ou tes archives ont explosé, pour que le réservoir ait eu à grossir … MAIS CECI N’A AUCUN IMPACT SUR LES PERFS
