Bonjour,
Depuis jeudi j'ai de gros problèmes de performance par intermittence, une requête qui doit normalement prendre quelques milliseconde peut prendre des minutes:
[2021-10-07 14:06:25] 1 row retrieved starting from 1 in 2 m 27 s 493 ms (execution: 2 m 27 s 419 ms, fetching: 74 ms)
Suis je le seul à avoir des problèmes ?
J'ai créé un ticket mais aucune réponse 3111270
Merci.
Bonjour @JulienH
Quelle requête SQL ?
Bonjour @Gaston_Phone
Un simple select avec une condition dans une table avec 200k d'entrée, normalement c'est super rapide.
La base de données refonctionne correctement actuellement mais ça va recommencer comme depuis jeudi…
Bonjour,
le seule qui pourrais répondre au niveau du forum serait @MikaelD1 qui de mémoire fait partie de la Team OVH qui gère les BDD.
Cordialement, janus57
Bonjour @janus57,
Oui c'est pour cela que je tente ma chance ici 
> Bonjour,
> Après vérifications, les administrateurs n'ont détecté aucune anomalie sur le serveur, mais le CPU à votre disposition a dû être limité pour protéger les autres clients de l'hôte, à la suite d'une trop grande consommation des ressources par vos sites.
> Ils vous invitent donc à vous assurer que toutes les tables sont indexées, et que les requêtes sont bien optimisées.
Je ne suis même pas surpris de la part d'OVH, ça fait 3 ans que ça tourne comme ça, les requêtes sont optimisées, je n'ai pas d'augmentation d'utilisation.
Comme d'habitude avec OVH, on se débarrasse du problème en disant que c'est la faute du client.
Salut @JulienH,
Quelques stats
Voici l'utilisation CPU de ton instance ces 6 derniers mois:
Comme tu peux le voir, l'instance est globalement plutôt bien utilisée. Son utilisation augmente doucement au fil du temps, sauf depuis le début du mois où il y a eu un décrochage.
Voici une journée typique il y a 5-6 mois:
Et maintenant, voici les dernières 24 heures:
Tu peux voir des plafonds à 200% de CPU (2 cores CPU utilisés chacun à 100%). Si ça plafonne, c'est que le service rendu n'est plus bon. Je vais d'abord t'expliquer pourquoi ils sont là, et ensuite on verra comment s'en sortir.
Déjà, comment ça marche chez les autres?
Chez Amazon RDS, Google Cloud & co, tu payes pour un nombre de cores CPU. Reprends le graph de ton utilisation CPU du mois de mai: tu vois que tu fais des pics à 400% de CPU (même un peu plus, vu que là c'est une moyenne à la minute), mais qu'en moyenne, tu utilises 50% de CPU. Si tu ne veux pas que tes services plafonnent (et donc dégrader tes perfs), tu dois te payer 4 cores. Ce qui est du gachis d'argent, vu qu'en moyenne tu ne te sers que de 50%.
Maintenant, comment ça marche sur OVHcloud CloudDB?
L'idée, c'est que tout le monde a besoin de «boosts» CPU sporadiques, mais jamais au même moment (et au plus on donne de CPU à ces besoins sporadiques, au moins ils prennent de temps, au moins on a de probabilité que quelqu'un d'autre en ait besoin au même moment).
Et comme on n'a pas envie de vous facturer des cores CPU que vous n'utilisez qu'une minorité de temps, on vous donne donc accès à 16 cores CPU (de beaux CPU d'ailleurs), mais pas tout le temps. Si tu te mets à consommer trop, trop longtemps, on va te limiter à 2 cores CPU. La règle est la suivante: si, sur les 15 dernières minutes glissantes, tu as consommé plus de 25 minutes CPU, alors on te limite à 2 cores. Et le calcul est refait toutes les minutes.
Ton cas
Dans ton cas, tu t'es mis à dépasser les limites CPU, donc tu as été plafonné à 2 cores CPU.
2 possibilités:
* Soit tu as, depuis début du mois, une différence de comportement (hausse du trafic, mise en production d'une nouvelle version qui changeraient les requêtes, etc…) qui expliquerait cette «explosion» de charge,
* Soit (et je pense plus que tu es dans ce cas) ton utilisation a monté tranquillement comme elle le fait depuis 6 mois et un goulot d'étranglement a été atteint. Au vu de ton utilisation mémoire, je penche plutôt pour cette piste: l'instance est beaucoup trop chargée en mémoire.
Avant de te demander de passer ton instance de 2 à 4 Go de mémoire, on va faire un petit test pour confirmer ou infirmer cette hypothèse: je viens de passer ton instance à 4 Go pour 48 heures. On attends et on regarde le comportement du CPU suite à cette augmentation de RAM.
Ça te va?
Bonjour @MikaelD1,
Merci beaucoup pour l'explication détaillée.
En effet je vois bien le pique dans le graphique mais je n'ai pas de hausse de traffic ou d'utilisation des services qui sont branchés sur cette base de données. Avec l'aide du dernier graphs je vais checker en détails mes logs afin de trouver quelque chose.
Une petite suggestion, ca serai top d'avoir le graphique du CPU dans le backoffice, ou au pire une mention dans les logs de la limitation de CPU afin d'avoir une idée du problème
Bonjour @JulienH,
Voici les dernières 24 heures, avec ton instance à 4 Go au lieu de 2 Go:
Soyons clair: ça n'a strictement rien changé et mon intuition sur le goulot d'étranglement côté mémoire n'était pas bonne. Ce test étant fini, j'ai repassé ton instance à 2 Go.
Par contre, je persiste à croire que:
ton utilisation a monté tranquillement comme elle le fait depuis 6 mois et un goulot d'étranglement a été atteint
On va donc continuer sur cette piste en attaquant la 2ème hypothèse: les index! Ce qui d'ailleurs appuyerait la réponse du support:
Ils vous invitent donc à vous assurer que toutes les tables sont indexées
Imagine, il te manque un index, et tu fais donc un full scan sur l'une de tes tables, et ce à toutes les requêtes. Avec 1000 rows, ta requête prends disons 0.1s. Les requêtes dépilent comme il faut, parceque ta requête est faite moins de 10 fois par seconde (je simplifie).
Tu ne modifies pas ton code, mais au fil du temps, ta table se remplit peu à peu. Le temps de traitement de ta requête monte à peu près linéairement avec le nombre de rows. Dans mon exemple (un peu trop simpliste je te l'accorde), les requêtes continueront à dépiler sans problème jusque 10000 rows. Au delà, on va passer plus de temps à empiler les requêtes qu'à les dépiler. Ça sature la mémoire, le CPU, ça explose les temps de réponse.
Pour confirmer ou infirmer cette hypothèse, est-ce que tu m'autorises à regarder tes requêtes (les requêtes, pas les réponses) et ajouter un index au besoin?
Bonjour @MikaelD1,
Merci beaucoup pour ton retour très complet encore une fois.
De mon coté j'ai checker les logs et j'ai remarqué qu'un petit malin scraper des pages un peu trop fortement (plusieurs pages par seconde) et assez longtemps. Fail2ban aurait du faire le job mais il était en status 255…
Concernant les index, je veux bien, normalement je ne fais pas de full scan et je pense avoir bien géré les index de mes tables en fonction de mes requêtes. Si tu modifies des index, je veux bien que tu donnes l'info en MP afin que je le documente, merci.
Bonjour @MikaelD1,
Pour info le problème persiste, actuellement par exemple, je ne trouve rien dans mes logs pour expliquer le comportement.
Je vois que le nombre de connexions par minute a augmenté un petit peu, mais cela peut s'expliquer par des temps de réponse plus long et donc plus de personnes en attente non?
Je me souvient du même problème en début d'année, ça avait duré 6/7 heures et c'était réglé par la suite, jusqu'à maintenant.
Bonjour @JulienH,
Je vois que le nombre de connexions par minute a augmenté un petit peu, mais cela peut s'expliquer par des temps de réponse plus long et donc plus de personnes en attente non?
Pourquoi ? Les visiteurs tenteraient un rafraîchissement de page ? Dans ce cas l'attente doit quand même être très très lentes.
La cloudDB est partagée sur plusieurs utilisateur avec de l'overprovisionning comme très très bien expliqué par @MikaelD1. Tu coup, bah effectivement tu n'a pas vraiment "la main" sur le fait que tu es limité provisoirement ou autre problème d'une autre instance client qui bouffe trop de puissance (mais je pense qu'OVH fait bien sont travail à ce niveau là, ton expérience actuelle le montre d'ailleurs).
A mon avis, dans 90% des cas, c'est un problème d'index. As tu vérifié correctement ce point. Je ne sais pas si tu peux avec ces instances BDD mais il y a des outils pour mettre en évidence ce manque d'indexation.
Comme tu parles de Fail2an, ton frontend doit être sur un dédié ou un VPS, pourquoi n'as tu pas ta BDD en local sur la même machine ? (c'est juste par curiosité).
Bonjour,
Pourquoi ? Les visiteurs tenteraient un rafraîchissement de page ? Dans ce cas l'attente doit quand même être très très lentes.
Pas forcement un rafraichissement, si la connexion est lente à retourner les infos, elle ne se libère pas et d'autres s'ouvrent pour service les nouveaux utilisateurs.
> A mon avis, dans 90% des cas, c'est un problème d'index. As tu vérifié correctement ce point. Je ne sais pas si tu peux avec ces instances BDD mais il y a des outils pour mettre en évidence ce manque d'indexation.
Je pense avoir bien fait le jobs, mais as tu un exemple d'outils stp ?
> Comme tu parles de Fail2an, ton frontend doit être sur un dédié ou un VPS, pourquoi n'as tu pas ta BDD en local sur la même machine ? (c'est juste par curiosité).
Je préfère que la partie BDD soit géré par des pros
Et voilà, après 2 heures de ralentissement, ça revient à un bon niveau. Du coup comme @TTY le souligne, c'est peut être un autre client sur l'instance qui bouffe toute les ressources.
Perso j'utilise le log des requêtes non indéxées en cas de problemes :
> log_queries_not_using_indexes = 1
Mais je ne sais pas si c'est possible en cloudDB.
Sinon tu peux le faire en environnement de dev local sur ton poste de travail.
Quand il y a un problème de perf un peu plus touchy, il y a le script mysqltunner qui donne la plupart du temps de bonnes indications… Mais c'est sur qu'il faut bien comprendre chaque changements de conf et cela peut prendre du temps pour se former (c'est très intéressant et peux resservir).
Dans PHPMyAdmin il y a peut être des outils ou alors tu peux écrire qq requêtes spécifiques pour les trouver ? (je sais pas).
> Je préfère que la partie BDD soit géré par des pros
C'est pas si dur
> Et voilà, après 2 heures de ralentissement, ça revient à un bon niveau. Du coup comme @TTY le souligne, c'est peut être un autre client sur l'instance qui bouffe toute les ressources.
Oui ou alors ton quotas est repassé en normal et tu peux à nouveau utiliser plus de ressources que ce que ton contrat prévoit. Je pencherais plus pour ce scénario.
Bonjour,
Oui ou alors ton quotas est repassé en normal et tu peux à nouveau utiliser plus de ressources que ce que ton contrat prévoit. Je pencherais plus pour ce scénario.
vu les explications et les graphs de @MikaelD1, c'est clairement le bridage CPU à "2vCPU" qui s'enclenche lors des phases de "ralentissement" suite à une trop grosse charge sur l’instance.
Par contre questions qui tue : mais y a pas un robot/script qui passe sur votre site pour faire du "scraping d'informations" et/ou des tests d'injection qui vous surcharge votre site ?
Cordialement, janus57
Bonjour @janus57,
C'est peut être une explication avant le 13 octobre, j'ai trouvé dans les logs un gros scrapers et fail2ban était en status 255…
Mais depuis, à chaque phase, je check les logs et fail2ban, pas de gros scraper.
@JulienH, je t'ai envoyé une optimisation de requête en message privé, les détails de l'index que j'ai créé, et surtout la méthode utilisée. Je te laisse dérouler la méthode sur les autres slow-queries et nous dire si ça va mieux pour ton instance =)
@MikaelD1 Merci beaucoup, je vais travailler dessus et revenir ici pour le feedback.
Bonjour @MikaelD1, c'est la deuxième fois que j'ai ce problème en 10 jours:
> 2021-10-21T12:27:03.000Z 2021-10-21 14:27:03 140349948344064 [Warning] mysqld: Disk is full writing '/dev/shm/#sql_25_4.MAD' (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)
Le serveur devient injoignable et je dois redémarrer manuellement le serveur, ce n'est pas normal que je dois redémarrer le serveur manuellement ?
Si je passe à 4 Go j'aurai plus de CPU ?