Comme annoncé, ce forum est passé en lecture seule au 1er janvier 2020. Désormais nous vous invitons à vous rendre sur notre nouvelle page communauté :
Image

A très bientôt !

optimisation base de données mysql

De l'installation à l'utilisation venez discuter de JEEDOM au quotidien
yves273
Timide
Messages : 322
Inscription : 18 janv. 2016, 11:13

optimisation base de données mysql

Message par yves273 » 23 juin 2018, 14:55

Bonjour,

J'ai eu fin mai un problème de cache qui m'avais bloqué l'accès à jeedom
Loic m'avait dépanné mais le pourquoi du cache qui grossit n'avait pas été élucidé.
De nouveau certaines pages comme celle de l'historique s'ouvre difficilement.
Je pense que certaines tables sont trop grosses (historyArch 925000lignes, history 625000lignes)
J'ai aussi beaucoup d'erreurs inconnues passagères qu'en j'enregistre un équipement.
le htop donne une erreur régulièrement
htop.jpg
htop.jpg (493.16 Kio) Consulté 1183 fois
voici l'error.log de 8h

Code : Tout sélectionner

700101  0:00:27 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
700101  0:00:27 [Note] Plugin 'FEDERATED' is disabled.
700101  0:00:27 InnoDB: The InnoDB memory heap is disabled
700101  0:00:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
700101  0:00:27 InnoDB: Compressed tables use zlib 1.2.8
700101  0:00:27 InnoDB: Using Linux native AIO
700101  0:00:27 InnoDB: Initializing buffer pool, size = 128.0M
700101  0:00:27 InnoDB: Completed initialization of buffer pool
700101  0:00:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 74912556444
700101  0:00:27  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 74917798912
InnoDB: Doing recovery: scanned up to log sequence number 74923041792
InnoDB: Doing recovery: scanned up to log sequence number 74928284672
700101  0:00:29  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 74933527552
InnoDB: Doing recovery: scanned up to log sequence number 74938770432
InnoDB: Doing recovery: scanned up to log sequence number 74944013312
InnoDB: Doing recovery: scanned up to log sequence number 74949256192
700101  0:00:33  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 74954499072
InnoDB: Doing recovery: scanned up to log sequence number 74956657194
180623  6:00:02  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180623  6:00:03  InnoDB: Waiting for the background threads to start
180623  6:00:04 InnoDB: 5.5.54 started; log sequence number 74956657194
180623  6:00:04 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
180623  6:00:04 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
180623  6:00:04 [Note] Server socket created on IP: '127.0.0.1'.
180623  6:00:04 [Note] Event Scheduler: Loaded 0 events
180623  6:00:04 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.54-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
comment puis-je méthodiquement optimiser tout cela avant que cela casse?
j'ai commencé à réduire la durée des historiques comment repérer les gros équipement consommateurs?

Gwladys
Timide
Messages : 250
Inscription : 27 avr. 2018, 18:22

Re: optimisation base de données mysql

Message par Gwladys » 17 sept. 2018, 10:01

Up

Cela me semble intéressant d'avoir les infos des experts pour optimiser les bdd plutôt que de chercher à augmenter les capacités.

Merci

jpma7
Timide
Messages : 78
Inscription : 29 juil. 2017, 16:58

Re: optimisation base de données mysql

Message par jpma7 » 17 sept. 2018, 10:22

Je suis car je pense que j'ai le meme probleme. ça sature et jeedom inaccessible

Gwladys
Timide
Messages : 250
Inscription : 27 avr. 2018, 18:22

Re: optimisation base de données mysql

Message par Gwladys » 19 sept. 2018, 09:54

Bonjour,

Petit UP, car je suis étonnée de ne pas avoir de retour pour l'optimisation et la maintenance de nos configurations.

J'ai bien trouvé le doc Jeedom d'optimisation pour la bdd, mais pas pour le reste, si besoin.

yves273
Timide
Messages : 322
Inscription : 18 janv. 2016, 11:13

Re: optimisation base de données mysql

Message par yves273 » 30 sept. 2018, 20:36

Bonjour à ceux qui ont des problèmes d'historisation.

suite à mon souci initial objet de ce sujet
- j'ai réduit la durée des historiques
- avec adminer j'ai exporté la base de données pour pouvoir récupérer ce que je souhaitais au cas où.
- j'ai suivi la grosseur de la base de données

cela m'a permis
- de comprendre ce que j'avais historiséet qui n'était pas nécessaire
- de mieux cerner ce que je voulais faire des historiques que je gardais
- de voir que j'avais mal paramétré les historiques dans jeedom ("archivé par paquet" que j'avais mis à 0 qui posait problème)
- de comprendre la répartition history et historyArch paramétré à 24h
- de voir que j'utilisais mal les virtuels pour historiser par jour
- de mieux utilisé adminer qui est ma foi agréable à utiliser quand on le connais mieux
cela a été long avec le peu de connaissance mysql que j'ai mais j'y suis arrivé
à ce jour history est à 23000 et historyArch est à 300000 et ne doit pas trop augmenter à terme.

il ne semble pas avoir beaucoup d'expert mysql dans le forum
si je peux aider...mais ce que j'ai écrit ce n'est que du bon sens mais il était difficile pour moi d'ouvrir les yeux sur mes insuffisances.de réflexion ou d'utilisation de jeedom.
cela n'empêche pas que je vide le cache régulièrement (page blanche) et que j'ai du mal a cerner pourquoi (cela ne semble provenir de la bdd)

pixluser
Timide
Messages : 45
Inscription : 20 févr. 2017, 10:50

Re: optimisation base de données mysql

Message par pixluser » 31 janv. 2019, 15:30

Salut Yves, merci pour ton message, comment depuis jeedom reparamétrer les tailles d'historyarch ? Et history ?

Répondre

Revenir vers « Utilisation »

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 23 invités