OVH Community, votre nouvel espace communautaire.

Connection à la base de donnée parfois très lente - Est-ce normal sur SQL mutualisé?


saxgard
02/11/2015, 12h36
Alors pour tous ceux qui ont suivi ce sujet, j'ai enfin des infos.

Avec l'aide d'Alex.P que je remercie mille fois, le problème a enfin été identifié. Il s'agit bien d'un soucis de configuration (root) d'ovh et pas d'un soucis de pics de charge ou je ne sais quoi.

Voilou après des mois d'acharnement, de tickets, de topics sur le forum, j'en vois enfin le bout. Et le mutualisé pourra enfin fonctionner normalement

saxgard
30/10/2015, 21h10
De mon côté Alex.P a effectivement observé un soucis qui n’est pas lié a un problème de charge de serveurs. J'espère maintenant que le problème sera enfin identifié et rectifié. car la c’est une vraie plaie.

Arenghien
30/10/2015, 17h59
Citation Envoyé par saxgard
Oui en fonction de l'offre c'est 10 ou 30 connexions simultanées. ca ne bloque pas 24h mais uiquement au moment ou il ya plus de 10 connexions en simulatnées.

Pour ma part concernant mes problèmes de lenteurs qui s'étaient calmées 3 jours environs reviennent en force et sois disant c’est normal et uniquement lié à la surcharge au niveau des serveurs sql !!
raz le bol
C'est bien que je me disais..donc l'explication d'OVH ne tient pas..

saxgard
30/10/2015, 13h27
Bonjour

@Kyon j'ai vu ça, malheureusement aucun changement, toujours des temps de connexion de 3-4-5 secondes

@Alex.P : je t'envoi un mail

Alex.P
30/10/2015, 11h26
Salut saxgard.

Veux tu tester un sql privé sur la nouvelle infra ?

Contact moi par email et on arrange ca ! (email dans mon profil)

Alex.P

Kyon
30/10/2015, 09h10
Hey saxgard !

http://travaux.ovh.net/?do=details&id=15012

mysql55-3.pro est de la partie aujourd'hui !

saxgard
29/10/2015, 14h10
Oui en fonction de l'offre c'est 10 ou 30 connexions simultanées. ca ne bloque pas 24h mais uiquement au moment ou il ya plus de 10 connexions en simulatnées.

Pour ma part concernant mes problèmes de lenteurs qui s'étaient calmées 3 jours environs reviennent en force et sois disant c’est normal et uniquement lié à la surcharge au niveau des serveurs sql !!
raz le bol

Arenghien
29/10/2015, 13h58
Citation Envoyé par saxgard
Bon de mon côté je commence le test en remplaçant le nom du serveur par mysql55-3.pro au lieu du nomdebdd.mysql.db. Pour voir si il y a pas un conflit a ce niveau là.

Il y a peut être des interférences également entre mysql5.1 et 5.5

En tout cas on dirait vraiment que le site rencontre des difficulté pour établir la communication avec le serveur SQL.

@Arenghien : actuellement j'ai accès a ton site.
Voilà la réponse que j'ai obtenu du support : Veuillez vous assurer de ne pas dépasser le nombre de connexions simultanées de votre base de données qui est limité à 10. - Kesako ?? Cela signifie-t-il que si 10 personnes sont en même temps sur le site ... C'est trop ??? Cela fait des mois que site fonctionne très bien .. et que pendant 24 h mon site ne fonctionnerait pas car 10 personnes se trouverait en même temps sur le site ??? Sérieux ?!

saxgard
24/10/2015, 15h09
En tout cas, pour moi, aujourd'hui j'ai eu 0 temps de réponses qui ont dépassé les 0.20ms, j'ai même pas de fichier log créé pour aujourd'hui, et c’est pas arrivé depuis des mois (depuis juin).
Je reste quand même sur mes gardes, d'une part parce que la journée n'est pas terminée, et d'autres part, si ovh n'ont rien touché et rien modifié le problème repointera surement le bout de son nez. Mais un retour d'ovh la dessus dans les travaux ou sur le forum serait franchement la bienvenue.

Arenghien
24/10/2015, 14h52
Citation Envoyé par saxgard
Depuis ce matin 2h je ne vois plus rien dans mes logs non plus et lorsque je navigue tout est très rapide. Mais je me méfie, et j'attends de voir les réponses du support.
Surtout que c’est déjà arrivé que pendant quelques heure stout fonctionne correctement (c'ets assez rare depuis quelques mois) et que ça reprenne ensuite.

Vu que rien n’est indiqué dans les travaux, je ne vois pas pourquoi après plusieurs mois le problème serait résolu. A suivre...

A coup sure j'ai affaire à la loi de Murphy juste au moment ou j'ai contacté le support et qu'ils vont jeter un œil à mon problème. Et là forcément ils vont rien voir pff

Et moi, j'attends toujours une réponse du support pour savoir pourquoi mon site est réapparu comme par miracle.. alors que je n'ai touché à rien..
JE viens de recevoir un mail d'enquête satisfaction espace client.. Je sens que je vais m'énerver tout en restant poli ;-)

saxgard
23/10/2015, 15h36
Depuis ce matin 2h je ne vois plus rien dans mes logs non plus et lorsque je navigue tout est très rapide. Mais je me méfie, et j'attends de voir les réponses du support.
Surtout que c’est déjà arrivé que pendant quelques heure stout fonctionne correctement (c'ets assez rare depuis quelques mois) et que ça reprenne ensuite.

Vu que rien n’est indiqué dans les travaux, je ne vois pas pourquoi après plusieurs mois le problème serait résolu. A suivre...

A coup sure j'ai affaire à la loi de Murphy juste au moment ou j'ai contacté le support et qu'ils vont jeter un œil à mon problème. Et là forcément ils vont rien voir pff

Arenghien
23/10/2015, 10h22
Tout est rentré dans l'ordre ce matin.... Et je n'ai touché à rien ! www.arenghien.be.. Je vais m'enquérir auprès d'OVH d'une explication...rationnelle ;-)

janus57
22/10/2015, 21h04
Bonjour,

J'ai du mal pour la configuration de serveur, j'avais d'ailleurs laissé tombé le sql privé a cause de ça (en plus du fait qu'on est vite dans la m*rde quand ca plante) :/
c'est pas pareil, sur les SQL privé (les nouveaux) plus besoin de toucher la config c'est OVH qui gère.

En tout cas sur SQL privé je ne constatais pas ces soucis d’accès a la bdd mais j'avais par contre des soucis de temps d’exécutions à certains moments lorsque je faisais un update sur une table pourtant quasi vide. je met ca sur le compte de la configuration mais je ne saurais pas quoi changer pour améliorer les performances au niveau des update.
peut être voir avec le support pour pouvoir tester les nouveau (Cf : https://forum.ovh.com/showthread.php...infrastructure).

Donc qu'est-ce qui pourrait justifier que sur sql privé il n'y a aucun soucis et pas sur mutualisé, hormis un problème de charge serveur (qui me parait peu probable dans le cas présent) ?
peut être pas le même matos/ même route réseau voir le même nombre de client (forcément 6€ HT/mois cela calme comparé a du SQL inclus dans l'offre).

Les SQL privé ont droit je pense (les nouveaux c'est sûr et pour les anciens bonne question), à un traitement de faveur dans le sens ou que c'est un supplément et que le client paye pour avoir un minimum de garanties (sur les ressources par exemple), et surtout il peut pas y avoir 10.000 clients par serveur si les ressources sont garantis (pas d'overselling normalement quand c'est garantie).

Cordialement, janus57

saxgard
22/10/2015, 20h50
J'ai du mal pour la configuration de serveur, j'avais d'ailleurs laissé tombé le sql privé a cause de ça (en plus du fait qu'on est vite dans la m*rde quand ca plante) :/
En tout cas sur SQL privé je ne constatais pas ces soucis d’accès a la bdd mais j'avais par contre des soucis de temps d’exécutions à certains moments lorsque je faisais un update sur une table pourtant quasi vide. je met ca sur le compte de la configuration mais je ne saurais pas quoi changer pour améliorer les performances au niveau des update.

Mais petite question, qu'il s'agisse des serveurs SQL privé ou sql mutualisé, ovh effectue le même procédé pour accéder aux serveurs? Étant donné que dans les 2 cas ils ne sont pas en local.. Donc qu'est-ce qui pourrait justifier que sur sql privé il n'y a aucun soucis et pas sur mutualisé, hormis un problème de charge serveur (qui me parait peu probable dans le cas présent) ?

PS en tout cas merci janus57 pour tes réponses et l'intérêt que tu portes a mon (mes) problème

janus57
22/10/2015, 20h36
Bonjour,

autre solution envisageable si c'est vraiment "juste" MySQL/SQL qui pose problème pour que le site fonctionne bien : utiliser un VPS ce qui donne un accès total à la configuration de MySQL (ou MariaDB ou autre) et en même temps permettrait de tester la connexion du mutualisé.

Après bien sûr le VPS c'est pas gratuit c'est minimum 3,59€ TTC/mois pour 10Go en SSD, mais cela ne peu pas être pire que actuellement et moins cher que le SQL privé (à condition de savoir administrer un serveur).

Cordialement, janus57

saxgard
22/10/2015, 20h27
@janus57 : bon j'ai encore tenté le support on verra, en fonction j'aviserais : contacter Octave voir changer d’hébergeur

Arenghien
22/10/2015, 18h32
Citation Envoyé par janus57
Bonjour,

OVH ne prévient plus pour les changement de MySQL car vous êtes censé utilisé user.mysql.db qui va automatiquement pointer vers le bon serveur MySQL ou se trouve vos tables, le but de cette adresse est pas de vous faire "chier" ou de vous cacher le nom du serveur MySQL, c'est juste pour que OVH puisse le changer à tout moment pour mieux répartir la charge ou faire une bascule si un problème est détecté.

@saxgard : je te conseil très fortement de contacter @olesovhcom si tu as pas envie de te prendre la tête et que tu as les données techniques.

Cordialement, janus57
Hé ben faut le savoir...;-) Merci pour le tuyau ! J'ai déjà contacté l'aide en ligne

janus57
22/10/2015, 18h05
Bonjour,

OVH ne prévient plus pour les changement de MySQL car vous êtes censé utilisé user.mysql.db qui va automatiquement pointer vers le bon serveur MySQL ou se trouve vos tables, le but de cette adresse est pas de vous faire "chier" ou de vous cacher le nom du serveur MySQL, c'est juste pour que OVH puisse le changer à tout moment pour mieux répartir la charge ou faire une bascule si un problème est détecté.

@saxgard : je te conseil très fortement de contacter @olesovhcom si tu as pas envie de te prendre la tête et que tu as les données techniques.

Cordialement, janus57

Arenghien
22/10/2015, 17h03
Pas le temps de faire çà pour l'instant.. Je teste çà ce week-end... A moins qu'OVH rétablisse çà ce week-end. M'ont déjà fait le coup au mois d'août en reconnaissant à demi-mot que c'était eux en cause... Je n'ai jamais reçu de leur part un mail disant que le mysql avait changé... La moindre chose serait de prévenir les gens

saxgard
22/10/2015, 15h16
Eh m*rde raz le bol, juste qu'en je dis ca bing ca recommence!

saxgard
22/10/2015, 15h09
Pour le moment mon test qui consiste à remplacer nomdebdd.mysql.db par mysql55-3.pro est concluant. J'attends de voir 1 ou 2 jours pour le confirmer (car ca peut etre un hasard et c’est peut être juste une petite accalmie avant que ca recommence). En tout cas depuis ce changement effectué vers 14h23 je n'ai eu aucune latence dépassant les 0.20 secondes. Rien dans mes logs.

Est ce qu'il est possible que ça puisse vraiment venir de là ?

Ce qui serait logique :

- Tous les anciens utilisent peut être encore les anciens noms de serveurs, d’où le fait qu'ils ne réagissent pas ici
- J'ai également l'impression d'avoir le même soucis sur un autre site qui utilise l’accès via bdd.mysql.db, alors que pour un 3eme site qui utilise l'ancien nom aucun soucis a priori.

Donc j'espère tenir enfin une piste sérieuse. Je vous tiens au courant.

saxgard
22/10/2015, 14h37
Quel filerz et quel serveur SQL? quelle version mysql 5.5?

As tu des logs pour vérfier tes temps de réponses ? peux tu faire de stests avec un simple script pour vérfier tes temps de reponses a ta bdd ?

Si on a le même pb on sera au moins 2

Arenghien
22/10/2015, 14h32
Ben moi pas.. Merci...
J'ai déjà çà il y a deux mois.. et puis c'est revenu... C'est dû à OVH assurément ...

saxgard
22/10/2015, 14h23
Bon de mon côté je commence le test en remplaçant le nom du serveur par mysql55-3.pro au lieu du nomdebdd.mysql.db. Pour voir si il y a pas un conflit a ce niveau là.

Il y a peut être des interférences également entre mysql5.1 et 5.5

En tout cas on dirait vraiment que le site rencontre des difficulté pour établir la communication avec le serveur SQL.

@Arenghien : actuellement j'ai accès a ton site.

Arenghien
22/10/2015, 14h18
Plus d'accès à mon site ! arenghien.be

Que se passe-t-il ?

Error displaying the error page: Application Instantiation Error: Could not connect to MySQL.

janus57
21/10/2015, 23h17
Bonjour,

J'ai pas de compte twitter :/ et pas certain qu'il apprécierait que je vienne le voir sur twitter pour un pb technique qui normalement doit être signalé via ticket.
non en générale c'est même le contraire si personne n'arrive à trouver cela l'intéresse fortement, surtout si c'est pour améliorer le tout (directeur technique c'est pas pour faire jolie chez lui), du moment que cela le "tic" et que l'on lui donne tous les détails tech il fait remonter à qui de droit voir regarde lui même.

J'y ai pensé également que cela peut être dû à le refonte de leurs serveurs mutualisés (php et mysql), mais ce qui m'étonne c’est que je sois le seul à constater de tels temps de réponses.
car de plus en plus de personne utilisent sans doute des caches SQL (pour les principaux CMS y a des plugins qui font ça très bien) et du coup les quelques pics passent inaperçus dans 90% des cas.
Où il sont partis ailleurs tout simplement.

PS : après verification chez o2switch la bdd est en local. Et vu qu'il n'y a aucun soucis, ca peut donc confirmer un problème aux niveaux des intermediaires entre le serveur mysql (la bdd) et le serveur php, chez ovh
normal, en générale cela va utiliser les socket unix (me semble que si PHP vois que c'est en local il utilise le socket MySQL plutôt que tpc/ip pour des raisons "logique") donc pas de TPC/IP

Cordialement, janus57

saxgard
21/10/2015, 22h24
qu'il y ait un peu de latence dû au protocole tcp/ip, aux clusters et autres VM, je peux le comprendre, quand ça concerne quelques ms. mais la on atteint trop souvent plusieurs secondes.

J'y ai pensé également que cela peut être dû à le refonte de leurs serveurs mutualisés (php et mysql), mais ce qui m'étonne c’est que je sois le seul à constater de tels temps de réponses.

J'avais déjà ouvert 3 tickets dont un avec Francois-G qui est intervenu sur ce topic, mais qui n'ont malheureusement abouti à rien. J'avais donné tous les éléments que j'ai en main, mais n'ayant pu leur indiquer une méthode pour constater le pb à coup sur, ils n'ont rien remarqué. Sachant que de toute façon ils ne doivent pas trop prendre le temps non plus pour faire toutes les vérifications et doivent automatiser pas mal de tests et passent surement a côté du pb.

Le graph "temps de réponses SQl " dans le manager ne semble pas significatif. Si on part dans l'idée que ça vient peut être du routage entres serveur php et sql, ça peut expliquer que ce graph ne soit pas suffisant. J'ai bien sur quelques pics mais pas forcément toujours aux endroits ou ils devraient y en avoir également.

Il faudrait déjà que je test pour le nom de serveur : mysql55-3.pro au lieu de nombdd.mysql.db. J'essayerais ça demain.
J'essayerais également de virer le php-fpm (mais il me semble l'avoir déjà testé et de toute façon ca parait pas logique)

J'ai pas de compte twitter :/ et pas certain qu'il apprécierait que je vienne le voir sur twitter pour un pb technique qui normalement doit être signalé via ticket.

En 10 ans chez ovh c'est certainement le problème le plus chiant et prise de tête que je rencontres

PS : après verification chez o2switch la bdd est en local. Et vu qu'il n'y a aucun soucis, ca peut donc confirmer un problème aux niveaux des intermediaires entre le serveur mysql (la bdd) et le serveur php, chez ovh

janus57
21/10/2015, 21h42
Bonjour,

Même si j'ai du mal à imaginer qu'ils ne constatent rien.
c'est possible si ils n'ont pas de sondes qui tests les latences entre les cluster web, cluster fichiers et cluster MySQL et les interactions entre les différents cluster.

De plus vu que les SQL sont sur le réseau il y aura toujours une latence minimal dû au protocol de communication qui est TCP/IP.

Donc si chez o2switch les SQL sont en local forcément cela va aller beaucoup plus vite car le SQL et le serveur web (qui traite le PHP donc) se trouve au même endroit sur la même machine et ce sera très reconnaissable car l'adresse du SQL sera "localhost" ou "127.0.0.1".

Aussi là OVH entreprend (si j'ai bien compris) une refonte de leur infrastructure mutualisé (d'où le fait que l'on dit adieu enfin à PHP4 + 5.0/5.1/5.2/5.3).

Donc peut être que le tout combiné (les migration MySQL 5.1 -> 5.5), la refonte des mutu (suppression vieux PHP) etc… le tout avec des milliers de clients sur les différents cluster engendre surement des effets collatéraux qui ne sont pas forcément visible sur leur monitoring (qui ne monitor peut être pas l'applicatif client).

Au passage, est-ce que dans le manager V6 (qui normalement a des graphs MySQL/PHP) vous arrivez aussi à voir les même phénomène que via le script ?
Car de mémoire les graphs dans le manager c'est ce que les admins de OVH voient (en surement plus précis et plus de détails), donc y a une chance que si cela n'apparait pas sur le manager les admins network + mutualisé n'arrive pas à le voir car chacun regarde de son côté plutôt que ensemble.

Du coup il faudrait les re-lancer via ticket en indiquant clairement et précisément (on évite le blabla autour sinon ils sont perdu et ceci est un constat) le problème rencontré.
Voir même lancer une pique au grand patron ici => https://twitter.com/olesovhcom/with_replies
Il sera ravi d'avoir les détails techs pour faire bouger les équipes mutu+network (car cela semble être les 2).

Cordialement, janus57

saxgard
21/10/2015, 21h15
@janus57 : Mes compétences s’arrêtent là, et ne saurais répondre à ça. Mais c'est pour ça que plus haut j'ai bien indiqué qu'il peut s'agir d'un problème de communication (routage) entre le serveur Php et le serveur mysql et pas forcement un pb avec la bdd elle même. J'avais fait mention des clusters notamment. Des problèmes de résolution DNS des user.mysql.db est peut être envisageable également. Mais difficile a mon niveau en tout cas de pointer du doigt un élément spécifique pour aider les admins d'OVH à identifier le problème. Même si j'ai du mal à imaginer qu'ils ne constatent rien.
Quoi qu'il en soit ces problèmes ont l'air lié à des changements effectués sur les serveurs ces derniers mois. (mai-juin). Je me bât depuis des mois avec ça.

janus57
21/10/2015, 20h22
Bonjour,

chez o2switch les MySQL sont aussi sur le réseau ? dans des container docker (ou a minima des machines virtuelle si j'ai bien compris comment est fait l'infra de OVH) ?

Car faut pas oublier que chez OVH c'est surtout l'interconnexion entre le cluster du mutualisé et le serveur MySQL qui va jouer en plus de la charge du lien + la charge du serveur/machine virtuelle.

P.S. de mémoire les mutu sont sur des VM pour pouvoir les bouger, d'où le fait que vous avez des adresse MySQL en user.mysql.db qui doivent donc éventuellement subir une résolution DNS (quelques ms en plus).

Cordialement, janus57

saxgard
21/10/2015, 19h01
Louim ca ne vient pas de la. ma base est déjà sur du mysql 5.5 depuis la mise en ligne du site en juin. J'ai d'ailleurs ces mêmes problemes depuis le début, mais ça c'est sérieusement aggravé. Et je soupçonne depuis le début cette intégration de la 5.5 sur les serveurs mysql. Mais c’est peut être une fausse piste.

Voici un petit script de test :

noubliepasdecrire.com/analyse_reponse.php

Normalement si personne n'a visité mon site un peu avant, vous devriez tomber sur le problème. Sinon quelques dizaines de réactualisations en faisant bien attention au résultat à chaque réactualisation, vous devriez tomber dessus. Lorsque le temps d’exécution est anormal il s'affiche en rouge.

Autre précision, sur o2switch le temps de connexion ne dépasse jamais les 0.02 secondes et il est en moyenne en dessous de 0.0006 secondes. la connexion est donc au moins 10 voir 100 fois plus rapide

louim
21/10/2015, 18h47
http://travaux.ovh.net/?do=details&id=13332

saxgard
21/10/2015, 18h05
Je n'ai pas mis en place de système de cache de mon côté (pas nécessaire pour le moment). requêtes optimisées, site pour le moment avec peu de données, et script MVC personnel très léger.

A priori c’est au niveau du temps d'accès a la bdd. Mais le fait de constater ces lenteurs quasiment 2 fois sur 3 après 2-3 minutes (difficile à calculer) sans activité sur le site, laisse en effet penser à un soucis de cache côté serveur ou un pb de routage. Même si les lenteurs peuvent intervenir même lorsqu'on est en train de surfer sur le site mais de façon plus aléatoire. Et ce côté aléatoire est vraiment très chiant et complique sérieusement l'analyse.
Maintenant difficile de savoir si c’est au niveau de la BDD ou de tout ce qu'il y a autour comme intermédiaire.

Une chose est certaine cela ne provient pas de mes requêtes (car c’est systématiquement la 1ere requête de la page qui apparait dans mes logs. par conséquent celle ou une connexion à la bdd est d'abord nécessaire). De plus ma base est vide,

J'avais pensé a ceci :

https://forum.ovh.com/showthread.php...mb4_unicode_ci

Mais apparemment selon un membre ca ne peut pas venir de la.

Ce qui m'étonne c’est de voir que personne ici ne constate le même soucis. Je n’arrête donc pas de faire des tests et recherche pour déterminer qu'est-ce qui pourrait de mon côté créer un tel soucis, et je ne vois absolument rien.

je vais poster ici un lien vers un script de test, qui permettra a ce qui le voudront bien de tester et constater le problème.

buddy
21/10/2015, 17h30
C'est bien le temps d'accès à la bdd ? Pas un système de cache ?

saxgard
21/10/2015, 17h21
C’est de pire en pire j'ai de plus souvent des temps de réponses supérieur à 4 secondes.
Il y a personne chez OVH capable de remarquer et identifier ce problème ?

C'est quasiment systématique, à la 1ere page visitée (si il y a pas eu de visiteurs dans la ou les minutes précédentes), le site patine et ça met entre 1 et plusieurs secondes. Autant dire qu'en gros presque chaque nouveau visiteur (vu que j'en ai peu) mettent du temps à atterrir sur la 1er page visitée. Je parle même pas des moteurs de recherche !

PS : je suis en train de faire des tests chez 02switch et je ne vois aucun soucis de ce genre pour le moment. Bien au contraire tout est bien plus performant.

saxgard
20/10/2015, 16h04
Autre point: J'J'arrive souvent à reproduire le problème en attendant 1 minutes ou 2 avant de visiter le site a nouveau (et si il n'y a eu aucun visiteur entre temps).

Mais ça n’empêche pas que même en surfant sur le site ça peut également mettre du temps. J'ai encore eu droit ces 10 dernière minutes en une 20-30 aines de pages visitées a un dépassement de 3 secondes a 2 reprises et quelques dépassement de 0.80 secondes.

saxgard
20/10/2015, 15h22
D'ailleurs j'ai regardé les logs d'ovh "web" et si c’est bien toi que je vois dans les logs autour de 14h47 (sachant comme indiqué que j'ai quasiment aucuun visiteurs et que ca correspond a peu près a l'heure de ton poste ici), je peux te dire que lorsque tu as visité la page http://www.noubliepasdecrire.com/dossiers/index il ya eu un temps de reponse de plus de 2 secondes. Tu as forcément du voir un petit moulinage avant de voir la page s'affichée.

Et idem a 14h46 quand tu as accédé a la page d'accueil : plus d'1 secondes de temps de réponse

Pour donner plus d'info,

Dans mon modele MVC j'ai une class (Design pattern Singleton) avec ces fonctions :

Code PHP:

   
protected function getMicrotime()
    {
            list(
$usec$sec) = explode(" ",microtime());
            return ((float)
$usec + (float)$sec);
    }

public static function 
getBdd() { 
             
          if (
self::$bdd === null) {            
              
               
// Création de la connexion
              
if(PDOERRMODE==true)
                    
$modeerror=array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION);
               else
                    
$modeerror=array(PDO::ATTR_ERRMODE => PDO::ERRMODE_SILENT);
                    
              
self::$bdd = new PDO('mysql:host='.BD_SERVEUR.';dbname='.BD_NOM.';'BD_UTILISATEURBD_PASSE
                      
$modeerror);
              
self::$bdd -> exec("set names ".ENCODAGEBDD."");
          }      

          return 
self::$bdd;
    }


// Exécute une requête SQL éventuellement paramétrée
   
public function executerRequete($sql$params null) {
     
      
$debut $this->getMicrotime();         
    
      if (
$params == null) {
         
$resultat $this->getBdd()->query($sql);    // exécution directe
      
}
      else {       
         
$resultat $this->getBdd()->prepare($sql);  // requête préparée
         
$resultat->execute($params);               
      }
      
      
$fin $this->getMicrotime();
      
$time $fin $debut;
      
      if(
DEBUGMODE)
      {
         
print_r($sql);
         
var_dump($time);
      }
      
      if(
$time>self::TIME_ALERT)
      {
         
$objLogs = new Logs();
         
$objLogs->createLog("time"$time."\r\nRequête :".$sql."\r\n");
      }
  
      return 
$resultat;
   } 
je fais mes try sur mon contrôleur principal

Que veux tu dire par "la boite noir d'OVH" ?

saxgard
20/10/2015, 15h03
Je n'ai jamais dis que c'était à chaque page visitée, Si c'était le cas le problème (je pense) aurait été identifié depuis longtemps). Je dis juste que c’est très fréquent d'avoir des temps de réponses serveur supérieur a 0.80 secondes et que le problème s'aggrave. Je commence a voir de plus en plus fréquemment des temps de réponses dépassant les 3 voir 6 secondes.

Sur 1000 pages visitée dans mes logs ça peut aller entre 50 et 100 pages qui ont mis plus de 1 secondes de temps de réponse serveur. En septembre c'éait autour d'une dizaine. Et j'ai environ un peut moins d'une dizaine de pages visitées qui mettent plus de 3 secondes

Rien que la juste avant de poster ce message, j'ai visité 10 pages de mon site et j'ai eu droit encore a une page qui a mis plus de 2 secondes!

20-10-2015 15:00:28 : 2.0212280750275

Quand ca tourne autour de 1 seconde ce n’est pas forcément flagrant pour l'utilisateur mais les fais sont la. par contre dès qu'on atteint les 2 secondes ou plus ca devient vraiment limite!

Au dela des 5 secondes on approche le timeout

POur répondre a tes questions ajoutés dans ton poste :

J'ai essayé en innodb et myisam, même soucis, avec pdo ou mysqli, idem.

oui j'utilise bien les exceptions

je ne fais pas de sauvegardes automatique ni de tache cron ...

J'ai quasiment aucun visiteurs, donc ce n'est pas une question de blocage de tables ou de lignes. Et je fais tres peu d'update/insert. C’est principalement du select

Rizz
20/10/2015, 14h50
Perso le seul truc qui me choque c'est que la config php des mutu ai un microtime avec autant de chiffre après la virgule

Sinon bah j'ai été sur ton site et je n'ai pas constaté de pb.

Niveau bdd je te conseil tout en innodb.. le modele myisam bloquant les lignes lorsqu'il y a des modifications.

Aussi lors d'un dump ( tu en a peut etre 1 par heure j'en sais rien ) tu lock toutes les tables ... donc lag possible.

Pour ce qui est du temps de connexion par contre ... dsl de pas pouvoir aidé c'est la boite noir d'ovh dans ce cas.

petite question quand meme ... tu utilises bien "try" ?

saxgard
20/10/2015, 14h40
20-10-2015 11:03:54 : 4.8204829692841 secondes
20-10-2015 11:51:53 : 1.6530561447144 secondes
20-10-2015 12:10:03 : 3.0285050868988 secondes
20-10-2015 13:58:49 : 1.8495011329651 secondes
20-10-2015 14:10:13 : 5.6094942092896 secondes
20-10-2015 14:18:56 : 2.8221549987793 secondes

Et encore je ne colle pas tous les temps de réponses serveur qui tournent autour des 0.80 secondes!! Sachant que mon site se charge sans problème en moins de 200ms en temps normal.

Trouvez vous ça normal sur un mutualisé d'avoir ce type de temps de réponse serveur ?

rappel de la preuve en image :



J'ai souscrit à une offre o2switch et ferais des tests pour comparer. En fonction j’étudierais la question de changer d'hébergeur.

saxgard
19/10/2015, 18h48
Ca c'était calmé vers 15h05 et ça recommence depuis 18h environ. Louim tu es sur quel filerz et quel serveur mysql ?

louim
19/10/2015, 16h52
Je confirme l'accès à mysql est très très lent voire impossible.
Qu'en est-il ?

saxgard
19/10/2015, 15h23
Piste possible, les clusters ou tous ce qui peut faire la liaison avec le serveur SQL.

Vers 12h ça c’est fortement aggravé avec des connexion pouvant dépasser les 6 s, voir 10 s (ce qui entrainait une erreur : Unknown MySQL server host 'nomduserveur' (1)

et il y a eu cette tache :

http://travaux.ovh.net/?do=details&id=15070

Petite amélioration ensuite mais toujours par intermittence des lenteurs pouvant encore dépasser les 7-8 secondes.

Jusqu'à présent je soupçonnait uniquement le serveur SQL ou la bdd mais peut être que les clusters ou autres choses sont à mettre en cause.
Un problème de liaison avec le serveur SQL ce qui expliquerait que je constate à mon niveau des lenteurs lorsque je fais ma connexion à la bdd : new PDO()

19-10-2015 15:03:21 : 7 secondes
19-10-2015 15:05:07 : 7 secondes de temps de réponses

et beaucoup de temps de réponses supérieur à 1 seconde

SVP si une personne du staff d'OVH pouvait passer par là.

saxgard
18/10/2015, 16h41
Dans mes logs persos je constate environ 100 fois sur 1000 pages visitées un délai de connexion à la base de donnée entre 0.30 secondes et 5 secondes

Voici une preuve des temps de réponses serveur élevé :



J'arrive quasiment à reproduire dans 80% des cas se temps de réponse serveur élevé lorsque je visite une page du site après 1 minutes d'attente (sans visites sur le site entre temps). Suffit de faire le test avec page speed insight pour s'en rendre compte.

Ca devient vraiment inacceptable et le staff d'OVh doivent forcements avoir de nombreux logs et outils pour détecter le problème. Impossible qu'ils ne voient rien ! Ca fait déjà 2 tickets sur ce problème et aucun n'a abouti

Soit il y a un sérieux problème sur les serveurs, soit certains hébergés sur mon serveur abusent fortement. De mon côté en local tout fonctionne sans soucis. Et je vois rien qui pourrait justifier un temps de connexion a la bdd ou un temps de chargement général aussi élevé (je ne cesse de le répéter d'ailleurs) .

saxgard
16/10/2015, 17h06
Bon, ça devient vraiment insupportable ces temps de connexions à la BDD parfois très élevés (un peu trop souvent). Ce n'est pas rare d'avoir plus de 2 secondes rien que pour se connecter ( new pdo() ) et j'ai même eu droit aujourd'hui a plus de 5s.

Sur mon site noubliepasdecrire.com en quelques dizaines de pages visitées j'ai obtenu plus de 13 fois une connexion à la Bdd qui a durée entre 1 et 2 secondes et j'ai eu droit également à plus de 5 secondes.

Bordel, qu'est-ce qui explique des temps de connexions aussi élevé toute la journée et de façon aussi aléatoire (du moins en apparence)?
J'avais déjà été traité dans un ticket mais rien n'a été observé par les admins (numéro ticket 2015091619009268), comment est-ce possible ??? N'ont-ils pas des logs du site pour constater ces pics. Si je suis le seul, qu'est-ce qui pourrait expliquer des temps de connexion élevés ? Que devrais je vérifier de mon côté ?

ok on est sur mutualisé, mais la il y a un problème. Ce n’est pas juste une question de partage de ressources

A chaque fois que je vois ce type de travaux (http://travaux.ovh.net/?do=details&id=15012,) j'ai de l'espoir que le problème soit enfin identifié, mais le problème est toujours là.

le 16/10/15 à

15:22:03 : 2.0588331222534 secondes
15:50:34 : 1.6062009334564 secondes
16:00:40 : 1.6734020709991 secondes
16:06:51 : 1.6679120063782 secondes
16:19:10 : 1.7588551044464 secondes
16:19:30 : 0.82216000556946 secondes
16:24:04 : 2.0032739639282 secondes
16:24:24 : 1.6939918994904 secondes
16:24:49 : 2.011403799057 secondes
16:26:56 : 0.2006618976593 secondes
16:32:32 : 1.7240769863129 secondes
16:42:02 : 5.6357960700989 secondes
16:48:29 : 2.0084578990936 secondes

Et c’est basé uniquement sur les quelques dizaines de clics que j'ai effectué moi-même sur mon site entre 15h et 17h, sachant que j'ai pour le moment très peu de visiteurs par jour.

Serait-il possible que quelqu'un se penche un peu plus sur le problème, de mon coté je ne sais vraiment plus quoi faire.

rappel :

noubliepasdecrire.com
cluster005
performance 1 (perf2014)
filerz2007
BDD SQL Perso sur mysql55-3.pro

saxgard
16/09/2015, 13h40
Merci, je vous ai envoyé le mail. J'espère que les administrateurs auront suffisamment de temps à me consacrer et de patience. Le soucis c'est qu'il faut parfois plusieurs centaines de pages visitées pour tomber dessus. Et parfois je tombe dessus 2-3 fois en quelques pages visitées. Par contre lorsque j'effectue les tests la nuit entre 1h et 5h c'est bien plus facile à observer.

C’est l'aspect a priori "aléatoire" qui est vraiment ennuyant. Et rend donc le problème difficile à reproduire.

Francois-G
16/09/2015, 09h40
Citation Envoyé par saxgard
Quelques infos supplémentaires.

Aujourd'hui j'ai eu plusieurs requêtes qui ont été très lentes :

15-09-2015 02:19:16 plus d'1 secondes (a cause de la connexion)
15-09-2015 02:19:16 plus de 4 secondes (surement a cause du "opening table" ou "statistics")

15-09-2015 10:51:03 2 secondes pour la connexion a la bdd

En rappelant que les requêtes ne sont pas à mettre en cause : La bdd est quasi vide (quelques dizaines d'enregistrements), et les requêtes ont été optimisées (index, vérification du explain)

Toujours en rappelant que mon nombre de visiteurs est très faible (site récent) et que ce type de problème risque d'être proportionnel à mon nombre de pages vues.
Je transmets tous vos tests à l'administrateur. Je suis désolé pour le temps d'investigation, nous ne parvenons pas à reproduire cette problématique pour le moment.

Je vous ai envoyé un mail pour le suivi, continuons l'échange par ce biais.

Cordialement,

François.

saxgard
15/09/2015, 14h29
Quelques infos supplémentaires.

Aujourd'hui j'ai eu plusieurs requêtes qui ont été très lentes :

15-09-2015 02:19:16 plus d'1 secondes (a cause de la connexion)
15-09-2015 02:19:16 plus de 4 secondes (surement a cause du "opening table" ou "statistics")

15-09-2015 10:51:03 2 secondes pour la connexion a la bdd

En rappelant que les requêtes ne sont pas à mettre en cause : La bdd est quasi vide (quelques dizaines d'enregistrements), et les requêtes ont été optimisées (index, vérification du explain)

Toujours en rappelant que mon nombre de visiteurs est très faible (site récent) et que ce type de problème risque d'être proportionnel à mon nombre de pages vues.

saxgard
15/09/2015, 11h48
Ok merci, j'attends alors ^^

Francois-G
15/09/2015, 09h52
Citation Envoyé par saxgard
Toujours pas de retour concernant ce soucis ?

J'ai encore peu de visites sur mon site (une dizaine / jour et quelques dizaines de pages visitées) et pourtant aujourd'hui j'ai eu encore droit aux 2 secondes pour se connecter à ma BDD, aux heures suivantes :

14-09-2015 18:11:38
14-09-2015 18:30:03

Et la journée n'est pas finie

Qu'es-ce qui pourrait expliquer que régulièrement il faille 2 secondes rien que pour se connecter à la BDD ? Et pourquoi 2 secondes ?

Entre les temps de réponses du serveur (php) qui approchent parfois 1s (cf : page speed insights, webpagetest) et ces problèmes aux niveaux des serveurs SQL, on ne peut pas vraiment dire, pour le moment, que l'offre performance 1 soit si performante.
Toujours en cours de check. J'attends le retour de l'administrateur, je ne vous ai pas oublié ;-)

Cordialement,

François.

saxgard
14/09/2015, 18h28
Toujours pas de retour concernant ce soucis ?

J'ai encore peu de visites sur mon site (une dizaine / jour et quelques dizaines de pages visitées) et pourtant aujourd'hui j'ai eu encore droit aux 2 secondes pour se connecter à ma BDD, aux heures suivantes :

14-09-2015 18:11:38
14-09-2015 18:30:03

Et la journée n'est pas finie

Qu'es-ce qui pourrait expliquer que régulièrement il faille 2 secondes rien que pour se connecter à la BDD ? Et pourquoi 2 secondes ?

Entre les temps de réponses du serveur (php) qui approchent parfois 1s (cf : page speed insights, webpagetest) et ces problèmes aux niveaux des serveurs SQL, on ne peut pas vraiment dire, pour le moment, que l'offre performance 1 soit si performante.

saxgard
10/09/2015, 14h28
Merci, j'espère enfin que le problème sera identifié.
Je me prend la tête de mon côté depuis des semaines à faire des tests en tout genre, à vérifier mes requêtes et j'en arrive toujours a une seule et même conclusion : C’est au niveau des serveurs MYSQL

En local je n'ai aucun soucis également.

PS : je fais également des SHOW PROCESSLIST et a priori aucun soucis de ce côté là

Francois-G
10/09/2015, 14h17
Citation Envoyé par saxgard
Bonjour

Dans mon site je vérifie les temps d’exécution de mes requêtes et crée mes propres logs de slow query.
J'avais constaté des requêtes qui apparaissaient dans mes logs alors qu'elles étaient très simples et optimisées (avec index, vérification du EXPLAIN etc.). Sachant que ma BDD est quasi vide (quelques dizaines d'enregistrements par table).
Je ne comprenais pas non plus pourquoi ça touchait généralement la 1ere requête exécutée dans le script.

J'ai donc créé un script très simple de test contenant uniquement la connexion à la bdd et 4-5 requêtes en effectuant également un show profile pour chaque requête.
Et j'ai effectuée des dizaines voir centaines de clics (rafraichissements de pages)
Au niveau de la connexion et pour chaque exécution de requêtes j'utilise microtime() pour tester le temps d’exécution, et c’est de cette façon que j'ai observé les problèmes suivants :

- La connexion a la base de données qui met parfois 2 secondes, ou plusieurs centaines de millisecondes
ou parfois pour les requêtes (au niveau du show profile) :
- Des temps élevés sur "opening table", "statistic" et à moindre importance "waiting for locking query"

J'ai essayé avec le moteur myisam ou innodb, même soucis
J'ai effectué des optimize, repair tables
PDO ou mysqli, aucun changement non plus

J'ai également essayé sur SQL privé, et je n'ai pas constaté ces soucis de connections

J'avais ouvert un ticket (ticket 2015070719023389) et j'avais obtenu la réponse suivante :



Hors depuis, les taches concernant les machines de sauvegardes ont été ouvertes et closed dans les travaux et pourtant aucun changement. Donc le problème que j'indique ne vient pas de là.

Infos :

noubliepasdecrire.com
cluster005
performance 1 (perf2014)
filerz2007
BDD SQL Perso sur mysql55-3.pro (j'ai créé une autre base de test sur mysql55-4.pro et j'ai observé le même soucis)

Pour mon script de test je ne peux indiquer le lien ici car il affiche des données que je ne souhaites pas divulguer

Par contre je peux indiquer quelques heures précises ou le temps de connexion a durée plus de 2 secondes sur ma base (hébergé sur mysql55-3.pro ) :

08-09-2015 12:00:04
09-09-2015 17:50:29
Ça c'est du retour de compétition Parfait !

Je remonte toutes ces infos à nos admins. Je reviens vers vous dès que j'en sais plus.

Cordialement,

François.

saxgard
10/09/2015, 11h59
Bonjour

Dans mon site je vérifie les temps d’exécution de mes requêtes et crée mes propres logs de slow query.
J'avais constaté des requêtes qui apparaissaient dans mes logs alors qu'elles étaient très simples et optimisées (avec index, vérification du EXPLAIN etc.). Sachant que ma BDD est quasi vide (quelques dizaines d'enregistrements par table).
Je ne comprenais pas non plus pourquoi ça touchait généralement la 1ere requête exécutée dans le script.

J'ai donc créé un script très simple de test contenant uniquement la connexion à la bdd et 4-5 requêtes en effectuant également un show profile pour chaque requête.
Et j'ai effectuée des dizaines voir centaines de clics (rafraichissements de pages)
Au niveau de la connexion et pour chaque exécution de requêtes j'utilise microtime() pour tester le temps d’exécution, et c’est de cette façon que j'ai observé les problèmes suivants :

- La connexion a la base de données qui met parfois 2 secondes, ou plusieurs centaines de millisecondes
ou parfois pour les requêtes (au niveau du show profile) :
- Des temps élevés sur "opening table", "statistic" et à moindre importance "waiting for locking query"

J'ai essayé avec le moteur myisam ou innodb, même soucis
J'ai effectué des optimize, repair tables
PDO ou mysqli, aucun changement non plus

J'ai également essayé sur SQL privé, et je n'ai pas constaté ces soucis de connections

J'avais ouvert un ticket (ticket 2015070719023389) et j'avais obtenu la réponse suivante :

Après investigation, ces lenteurs s'expliquent par le fait que les sauvegardes
nocturnes des serveurs MySQL mysql55-3.pro et mysql55-4.pro mettent beaucoup
de temps et se terminent en milieu voir en fin d'après midi. Ceci étant dû aux
machine de sauvegardes qui sont saturées.

Le serveur mysql55-4.pro héberge aussi un autre client qui abuse de ses
ressources et crée des perturbations. Nous travaillons à le faire migrer vers
une autre solution.

Nous sommes au courant de ces lenteurs et le serveur de sauvegardes des
mysql55-3.pro et mysql55-4.pro doit être remplacé.
Hors depuis, les taches concernant les machines de sauvegardes ont été ouvertes et closed dans les travaux et pourtant aucun changement. Donc le problème que j'indique ne vient pas de là.

Infos :

noubliepasdecrire.com
cluster005
performance 1 (perf2014)
filerz2007
BDD SQL Perso sur mysql55-3.pro (j'ai créé une autre base de test sur mysql55-4.pro et j'ai observé le même soucis)

Pour mon script de test je ne peux indiquer le lien ici car il affiche des données que je ne souhaites pas divulguer

Par contre je peux indiquer quelques heures précises ou le temps de connexion a durée plus de 2 secondes sur ma base (hébergé sur mysql55-3.pro ) :

08-09-2015 12:00:04
09-09-2015 17:50:29

Francois-G
10/09/2015, 10h02
Citation Envoyé par saxgard
Bonsoir

J'aimerais savoir si c’est normal d'avoir parfois 2 secondes de latence rien que pour se connecter à la Base de donnée sur les SQL mutualisés (perso et pro) ?

Dans 95% du temps la connexion se fait entre 0.002 secondes et 0.03 secondes et de temps en temps elle prend 2 secondes.

J'ai essayé sur plusieurs serveur SQL avec mysql 5.1 ou mysql 5.5 et je vois le même problème partout.

Est-ce normal et à quoi cela correspond ? Sachant que cette latence, lorsqu'elle survient ne dépasse jamais les 2 secondes (du moins d'après mes tests).
Bonjour,

Comment avez-vous obtenu ces résultats?

S'agit-il d'une simple connexion à PhpMyAdmin? D'une requête SQL? Avez-vous des logs ou un exemple afin d'investiguer?

Quel est le nom de domaine concerné?

En bref, pouvez-vous nous en dire plus?

Cordialement,

François.

saxgard
09/09/2015, 18h20
Bonsoir

J'aimerais savoir si c’est normal d'avoir parfois 2 secondes de latence rien que pour se connecter à la Base de donnée sur les SQL mutualisés (perso et pro) ?

Dans 95% du temps la connexion se fait entre 0.002 secondes et 0.03 secondes et de temps en temps elle prend 2 secondes.

J'ai essayé sur plusieurs serveur SQL avec mysql 5.1 ou mysql 5.5 et je vois le même problème partout.

Est-ce normal et à quoi cela correspond ? Sachant que cette latence, lorsqu'elle survient ne dépasse jamais les 2 secondes (du moins d'après mes tests).