Bonjour, pour un site que je gère et un site gèré par un ami, tous deux utilisant une base de données OVH privée 512Go RAM, je constate une utilisation de la RAM de la base de données qui va croissante mais jamais ne retombe sauf redémarrage.
Pour mon site, cela ne pose pas trop de problème, car la fréquence de redémarrage est faible.
De +, j'ai upgradé de mysql 5.5 en 5.7 et cela semble un peu amélioré la consommation RAM d'une manière générale. J'en ai aussi profité pour augmenter la taille de mémoire tampon inno_db.
Mais pour mon ami, le problème est bcp plus gênant.
Ma question est :
- est-il normal d'avoir une consommation RAM qui ne fait qu'augmenter et jamais ne descend sur mysql ? Sur quoi peut-on jouer, dans le contexte OVH cloud privé, wordpress pour améliorer la situation ? (hormis désactiver des plugins wordpress) ?
Parce qu'augmenter la capacité RAM ne me semble pas la bonne solution, doubler la capacité RAM revient à diviser par 2 le temps entre deux dépassements mémoire, mais n'est absolument pas une correction....
Fuite mémoire Base de données MySQL 5/7 contexte Wordpress
Sujets apparentés
- Redis 4.0 et MongoDB 4.0 maintenant disponibles !
7332 
20.09.2018 15:18
- Connexion Cloud MySQL avec phpMyAdmin
4453 23.04.2018 07:44
- Problème connexion BDD avec PDO
4275 07.11.2018 22:00
- Changer de Version de MySQL
3778 02.11.2023 13:46
- Comment configurer une datasource dans grafana sur DBTimeSerie
2796 21.06.2017 15:24
- [Sondage officiel] DBaaS : quel système NoSQL souhaitez-vous en priorité ?
2760 19.10.2016 13:23
- Perte Identifiants pour acceder à la base Wordpress et eviter les spams
2505 02.02.2021 14:16
- SQL privé Postgre : could not translate host name
2375 06.04.2018 17:13
- Lier une BDD de mon SQL Privé à mon site Wordpress
2351 16.05.2020 17:08
- Je ne parviens pas à reboot mon site WP
2307 27.12.2020 08:28
J'avais déjà remonté le problème avec Mariadb, apparemment c'est normal...
https://community.ovh.com/t/erreur-1053-server-shutdown-in-progress/12491/18
Salut,
Depuis cette réponse, de grosses modifications ont été faites à propos de la gestion de la mémoire sur les CloudDB. Je t'invite plutôt à aller voir https://community.ovhcloud.com/community/fr/amelioration-de-la-gestion-de-la-memoire-sur-les-clouddb?id=community_question&sys_id=c734f18c81928210f0780f07683eb20f?u=mikaeld1 ce sujet.
Oui, parceque cette courbe inclut la mémoire «cached». Pour faire simple, quand tu lis un fichier sur le disque, il est mis en RAM (c'est un passage obligé). Quand tu n'as plus besoin de ce fichier, au lieu de libérer la RAM, Linux fait un truc excellent, c'est de le laisser là et de marquer cette RAM comme disponible.
- Si tu dois relire le même fichier, il est déjà en RAM et ça te fait gagner beaucoup de temps.
- Si tu as besoin de RAM et qu'il n'y en n'a plus de libre, alors le fichier est enlevé de la RAM à ce moment là, et tu as la RAM dont tu as besoin.
Bon, par contre, clairement, ce n'est pas trivial, on doit clairement changer la métrique ou mieux l'expliquer…
@FredericR1 : peux-tu me donner le nom de l'instance posant problème qu'on y jette un œil?
bonjour oui désolé je ne découvre cette réponse que maintenant, sont concernés 2 instances sql privées, par contre, ça me gêne d'écrire l'instance en question en public et de donner les accès ...
Je vous ai envoyé en mot de passe les noms des 2 bases SQL privé concernées
Premier constat, tes instances se portent plutôt bien. La plus petite (0.5 Go) s'est fait OOM kill 7 fois ces 7 derniers jours, la plus grosse (1 Go) s'est fait OOM kill 1 fois ces 7 derniers jours. Comme les instances redémarrent en moins de 10 secondes, on parle d'à peu près une minute d'indispo commulée par semaine. Mais on va creuser.
Je constate 2 types d'utilisation sur ton instance 0.5 Go:
* L'utilisation «normale», c'est à dire 99.7% du temps: l'instance est plutôt bien utilisée en terme de mémoire. Une instance supérieure apporterait un peu d'air, mais tu n'es pas non plus obligé de passer par là. Tu peux par exemple vérifier si tu n'as pas de plugin Wordpress qui font des requêtes un peu trop gourmandes (j'ai constaté que c'était souvent une cause d'utilisation importante de la DB).
* L'utilisation «inhabituelle». Une image parle plus que de longues phrases:
On y voit un énorme pic d'utilisation. Au milieu du pic, un redémarrage de l'instance à cause d'un full de mémoire. Je vois ce pic au niveau des select, des insert, des updates, du CPU, du réseau, du disque… J'ai vérifié, ça ne correspond à rien chez nous (dump, backup, mise à jour,…). Sais-tu à quoi correspond ce traffic? Ça te semble légitime?
À noter que tu si tu souhaites récupérer les métriques de ton instance (ton instance remonte **beaucoup** de métriques super intéressantes), tu as https://docs.ovh.com/fr/hosting/recuperer-les-metriques-dun-sql-prive-sur-grafana/">ici un guide pour le faire.
Super réponse déjà ! merci !
Concernant le pic, je pense qu'il peut s'agir d'une mise en cache de wp-rocket, sans preuve ceci dit mais ça ne m'étonnerait pas.
NB : je suis passé à la dernière version de mysql et je vois une nette amélioration du phénomène depuis, je m'étonne toujours du fait que la mémoire monte toujours et jamais ne redescend ... Mais je pense qu'il s'agit de fuite, des sockets mal fermées, suite je pense, à des arrêts de processus jugés gourmands par ovh ... et donc pas de fermeture des requêtes SQL en cours de ce fait.
Après, pour revenir sur votre question, je pense que le pic peut correspondre tout simplement à un pic de connexion, peut être un crawl. Mais si on regarde précisément, et pour revenir à la question de départ, ce pic est sans effet sur la consommation mémoire:
tout au plus il crée un petit palier, mais ce n'est pas lui qui génère la montée en mémoire progressive, qui elle s'effectue certes lentement mais en continue - mais c'est peut être normal ... Il me semble avoir déjà aperçu qu'un script de supervision mis en place par OVH générait des erreurs sur mon serveur. Cf. https://community.ovhcloud.com/community/fr/erreur-log-base-de-donnee-mysql?id=community_question&sys_id=1516b508fdde8e902d4c483e6acd51f6; mais même s'il peut avoir une part de responsabilité, la pente de la courbe mémoire indique qu'il ne peut être seul responsable ... cette pente n'est pas non plus proportionnelle au trafic, il faut peut être aller chercher du côté des plugins qui interviennent en mode admin effectivement ... J'avais déjà regardé les slow query logs à un moment mais je n'avais rien vu de bien éclairant.
Bonjour Monsieur,
nous rencontrons le même problème sauf que cela ralenti considérablement le site jusqu'à des erreurs 504/502 gateway. Malgré une restauration, nettoyé la BDD, corriger les slow query etc... mais rien n'y fait.
Pouvz-vous y jeter un coup d'oeil et nous éclairer sur des solutions ? Que ce soit du côté de OVH ou du notre même si nous pensons avoir déjà bien creusé.
Wordpress
Hébergement perf2014x1 (mutualisé)
Option CDN désactivité
PHP 7.3
MySQL 5.7
SQL privé
RAM 512
SSL Oui - LETSENCRYPT - DV
Cluster 20 Graveline 1
Cdt,