Pb SQL - Jeedom instable dpuis 2 jours

[fcna]

Bonjour à tous,

depuis 2/3 jours, mon jeedom est trés instable. Souvent il ne repond pas (HTML, SSH) pendant quelques temps, soit il est complemeent mort. Quand je fais un hard reboot, ca remarche.

Je suis sur SSD, donc pas de souci de SD. J'ai cherché sur le forum sans trouver de réponse.

Je pense que mon souci vient de mysql.

Dans les log http.error, j'ai trés souvent :
[Fri Feb 17 11:08:28.993648 2017] [:error] [pid 21676] [client 127.0.0.1:57272] PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' in /var/www/html/core/class/DB.class.php:37

le dmesg me dis :

Code : Tout sélectionner

[  930.087876] Out of memory: Kill process 1358 (mysqld) score 65 or sacrifice child
[  930.088002] Killed process 1358 (mysqld) total-vm:329228kB, anon-rss:41376kB, file-rss:0kB, shmem-rss:0kB
[  930.916416] systemd[1]: systemd-journald.service stop-sigterm timed out. Killing.
[  930.918263] systemd[1]: Starting Cleanup of Temporary Directories...
[  930.926256] systemd[1]: Starting Journal Service...
[  930.949071] systemd[1]: systemd-journald.service: main process exited, code=killed, status=9/KILL
[  930.950074] systemd[1]: Unit systemd-journald.service entered failed state.
[  930.955400] systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
[  930.955804] systemd[1]: Stopping Journal Service...
[  930.955928] systemd[1]: Starting Journal Service...
[  930.963977] systemd[1]: Started Journal Service.
[  931.365443] systemd-journald[5548]: File /run/log/journal/3d7672f1ec7248608a279a3270ccf85e/system.journal corrupted or uncleanly shut down, renaming and replacing.
[  932.752322] systemd-journald[5548]: Received request to flush runtime journal from PID 1

pourtant j'ai bien su swap :

Code : Tout sélectionner

             total       used       free     shared    buffers     cached
Mem:           495        251        244         61          8        100
-/+ buffers/cache:        142        352
Swap:          127          0        127

Quan le systeme rame, j'ai le process Kswapd qui prend trop de cpu ...


Bref, mon analyse est que Mysql déconne et explose au bout d'un moment mais je ne sais pas comment réparer.

Merci d'avance

[thanaus]

Tu as un problème de consommation mémoire à un instant T... d'ou le kill par l'OS du process pour libérer de la mémoire.
[ 930.087876] Out of memory: Kill process 1358 (mysqld) score 65 or sacrifice child

Il faut que tu regardes régulièrement la consommation mémoire de tes processus pour savoir qui en consomme le plus et pourquoi.
Tu as changé récemment de configuration ?

[fcna]

je vois rien de spécial dans la conso ... et pas changer grand chose ..

[thanaus]

Si tout fonctionnait bien il y a quelques jours et que tu as un problème de mémoire suite à des changements (même mineur), il faut voir du côté de ces changements. En tous les cas et vu le log, il s'agit d'un problème de consommation mémoire.

La commande ci-dessous te permet de savoir les processus qui consomment le plus de mémoire :

Code : Tout sélectionner

ps aux --sort -rss

[fcna]

merci pour la commande. Cela confirme que c'est mysql qui bouffe le plus ...

[fcna]

Bonjour à tous, j'ai résolu mais pb et je vous fais part de ma solution.

Donc, effectivement, c'était bien mysql qui partait en vrille. Du coup, j'ai été voir dans la BdD. et la surprise, la table historyArch était immense (he oui depuis 2015, j'avais des enrrgistrement). Du coup, j'ai bien vider (passer de 204 kLignes à 70k), et maintenant ca marche .... et en plus le systeme est pus réactif. Je suis passé d'une charge supérieur à 1 (voir plus) a 0,5 .... c'est dingue

Du coup, si un grand gourou passe par la, je me demande quand si tous les problèmes que je vois sur les pb mysql ne viennent pas de tables trop grosses dans la bdd.

Vous en pensez quoi ?

[Anonyme]

Contenu supprimé à la demande de son auteur

[thanaus]

Bonjour à tous, j'ai résolu mais pb et je vous fais part de ma solution.

Donc, effectivement, c'était bien mysql qui partait en vrille. Du coup, j'ai été voir dans la BdD. et la surprise, la table historyArch était immense (he oui depuis 2015, j'avais des enrrgistrement). Du coup, j'ai bien vider (passer de 204 kLignes à 70k), et maintenant ca marche .... et en plus le systeme est pus réactif. Je suis passé d'une charge supérieur à 1 (voir plus) a 0,5 .... c'est dingue

Du coup, si un grand gourou passe par la, je me demande quand si tous les problèmes que je vois sur les pb mysql ne viennent pas de tables trop grosses dans la bdd.

Vous en pensez quoi ?

Je pense que tu as trouvé la cause principale de tous les utilisateurs qui ont ce type de bug... Par contre, je suis surpris que les processus MySQL consomment autant de mémoire pour si peu de données. J'ai travaillé sur des tables contenant des millions d'enregistrements et je n'ai pas remarque à ce point une consommation mémoire excessive.
Peut-être un problème de requête ou les index poseraient problème dans le core du code Jeedom....

[fcna]

pour le coup, je maîtrisais un peu les bases de données. j'ai aussi travailler sur des bases de données plus grosses mais pas sur un RPI !!!

Sinon, Magicgg, oui je connais le fonctionnement de l'historique, mais si le problème est confirmés par d'autres, et uniquement dans ce cas, je trouve que l'historique est du coup assez mal fait dans la gestion. Perso, je suis aller directement dans la base de données.

[caribouf]

@fcna

Salut,
Comment tu fais pour accéder à la BDD, histoire de purger un peu ?
Car j'ai le même souci depuis plusieurs mois. J'ai changé mon RPi2 pour un 3 il y a 3 semaines, avec déport de Jeedom sur SSD, et toujours cette fichue erreur qui revient de manière complètement aléatoire. Ce matin l'erreur est revenue, et là j'en ai vraiment ras-le-bol, et le waf commence à passer en négatif...
Merci d'avance de ta réponse.

[Morlock]

suis preneur aussi
rpi3 sur ssd et mon swap qui gonfle, gonfle puis crash
tmp normal lui !
je voudrais bien jeter un oeil et voir la taille de ma bdd

[fcna]

Dans configuration, tu as dans l'onglet Base de données, puis se connecter.
Ensuite, dans la nouvelle fenêtre, tu selectionne Jeedom
et la, tu regardes la tailles de historyArch.

Ensuite, plusieurs options:
tu utilises l'écran historique pour nettoyer --> plus safe
Tu vident la table
tu vident une partie de la table via un select

[caribouf]

Merci pour ta réponse rapide.
J'ai une taille de 9,977,856 et 225,233 rows. C'est beaucoup ou pas ? Je ne me rends pas compte en fait.

[fcna]

Merci pour ta réponse rapide.
J'ai une taille de 9,977,856 et 225,233 rows. C'est beaucoup ou pas ? Je ne me rends pas compte en fait.

pour moi oui. un peu de ménége s'impose. Si pb, une petite sauvegarde avant

[fcna]

et tu me dira si la charge systeme a baissé

[Morlock]

Pour ma part je ne sais pas me connecter
par défaut c'était le login utilisateur qui était déjà indiqué, j'ai aussi essayé root

[fcna]

Pour ma part je ne sais pas me connecter
par défaut c'était le login utilisateur qui était déjà indiqué, j'ai aussi essayé root

login et password juste en dessous du bouton dans la page conig

[Morlock]

arfff le boulet !!! lol
j'en ai un peu plus
data length 33,095,680
index length 14,172,160
rows ~ 658,991

[fcna]

aprés je ne suis pas un spécialiste, mais 650 000 lignes sur un RPI, ca me semble énorme ...

[Anonyme]

Contenu supprimé à la demande de son auteur