1001.eu.clouddb.ovh.net001.eu.clouddb.ovh.net est le nom d'hôte de la base
Merci.
>ping 1001.eu.clouddb.ovh.net001.eu.clouddb.ovh.net
PING clouddb015.eu008.clouddb.ovh.net (141.94.24.136) 56(84) bytes of data.
64 bytes from 141.94.24.136 (141.94.24.136): icmp_seq=1 ttl=44 time=17.0 ms
64 bytes from 141.94.24.136 (141.94.24.136): icmp_seq=2 ttl=44 time=16.9 ms
Oui c'est bien accessible depuis le net et la latence est bonne depuis chez moi (17ms).
Faite un ping comme le suggère @janus57 depuis vos locaux et donnez nous le résultat.
Voici :
64 bytes from 141.94.24.136 (141.94.24.136): icmp_seq=1 ttl=45 time=23.0 ms
64 bytes from 141.94.24.136 (141.94.24.136): icmp_seq=2 ttl=45 time=21.1 ms
Merci
La connectivité semble bonne.
Je ne vais pas pouvoir vous conseiller beaucoup plus.
- Activation des log requêtes lentes et non indexés (comme vu plus haut) faite un ticket pour cela au pire.
- Vérifiez que la charge du cloudDB ne soit pas trop importante (je pense qu'il doit y avoir des graphiques pour ça dans le manager)
Si ces 2 points sont OK, alors il va falloir prendre un prestataire pour trouver ou est le "goulet" d'étranglement et résoudre votre problème.
@janus57 qu'en penses tu ?
Bonjour,
CloudDB = SQL privé ?
non c'est 2 services différent
CloudDB == instance SQL accessible depuis internet (si IP mis en liste verte)
SQL privé == instance SQL accessible seulement et uniquement depuis les hébergement mutualisés.
Pour le CloudDB voici la documentation : https://docs.ovh.com/fr/clouddb/configurer-optimiser-son-serveur-de-base-de-donnees/
Normalement vous avez accès à un panel de graphiques et surtout des conseils en fin de guide
Le dernier test que j'aurais fait c'est de mesurer (en PHP) le temps que PDO met à se connecter au serveur SQL puis a fermer la connexion.
Par contre pour moi le ping est "pas bon", une très bonne latence serait inférieur à 5ms, une latence "okey" serait à 20ms grand maximum, au delà ça commence à être mauvais.
Peut être que @MikaelD1 (Team OVH) pourrais jeter un coup d'oeil
Cordialement, janus57
Bonjour,
> CloudDB == instance SQL accessible depuis internet (si IP mis en liste verte)
> SQL privé == instance SQL accessible seulement et uniquement depuis les hébergement mutualisés.
Ceci était vrai il y a encore quelques mois, mais ne l'est plus maintenant ! Toutes les instances sont accessibles depuis internet, et un bouton permet de mettre en liste verte les clusters des hébergement mutualisés:
Concernant le problème de lenteurs, je constate que la RAM plafonne souvent à 100% avec certains pics qui occasionnent un OOMkill (Saturation de la RAM allouée), entraînant un redémarrage de la base toutes les 24/48 heures depuis environ une semaine, ce qui peut causer des lenteurs importantes:
1. L'application lance un traitement lourd
* L'instance sature sa RAM et redémarre
* L'application voit qu'elle perd la connexion avec la base de données
* L'instance redémarre avant que l'application ne dépasse son timeout
* L'application voit le retour de la base et relance son traitement
* Cette fois-ci le traitement passe car de la RAM a été libérée suite au redémarrage
De votre point de vue, le premier traitement a été effectué en quelques secondes au lieu de quelques millisecondes
Une autre explication possibles est la suivante: comme la RAM est entièrement allouée, le conteneur utilise une partie de sa SWAP (D'une certaine manière de la mémoire déportée sur le disque dur) qui est beaucoup plus lente lors du traitement.
Il serait judicieux de voir comment optimiser le contenu de la base de données ou les requêtes.
Si aucune amélioration de ce coté n'est possible, la solution la plus simple serait de passer sur une offre supérieure.
Bonjour,
Ceci était vrai il y a encore quelques mois, mais ne l'est plus maintenant ! Toutes les instances sont accessibles depuis internet, et un bouton permet de mettre en liste verte les clusters des hébergement mutualisés
Merci pour l’information, car il ne me semble pas avoir vu passé cette nouveauté/changement.
Du coup en faite le terme "SQL Privé" n'existe plus, maintenant ce sont des "CloudDB" qui sont fournis avec les hébergements Perf ?
Note : tout ces termes ça commence à être chiant pour s'y retrouver au niveau des produits OVH…
Cordialement, janus57
Merci pour ce retour @FabienB42
@janus57
>Par contre pour moi le ping est "pas bon", une très bonne latence serait inférieur à 5ms, une latence "okey" serait à 20ms grand maximum, au delà ça commence à être mauvais.
La vache tu es pas un peu dur ? Je n'ai jamais eu un ping inférieur à 13ms depuis mes locaux (fibré Orange Pro FTH) quelque soit le serveur (bon je suis en zone rurale dans le sud Ouest…)
>Note : tout ces termes ça commence à être chiant pour s'y retrouver au niveau des produits OVH…
+1
Bonjour,
La vache tu es pas un peu dur ?
oui et non, sur un système synchrone j'ai 2ms maximum (en tête) pour ne pas percevoir une dégradation de perf.
Du coup je prend un facteur x10 pour un système "standalone" => 20ms
Je n'ai jamais eu un ping inférieur à 13ms depuis mes locaux (fibré Orange Pro FTH) quelque soit le serveur (bon je suis en zone rurale dans le sud Ouest…)
je n'ai jamais eu l'idée de faire du SQL distant à travers internet, encore moins quand l'éditeur ne peut pas me certifier qu'il va utiliser du TLS.
Cordialement, janus57
Merci.
Bonjour et merci pour la réponse,
Non, l'application ne lance pas de traitement lourd du tout, ce sont de simple requête SQL toute bêtes (visible sur l'un de mes messages précédents).
Je viens de recharger la page d'accueil de l'application (toujours aussi longue) et je n'ai constaté aucun dépassement de RAM supplémentaire depuis mon tableau de bord de mon espace client.
Merci de noter que notre Prestashop, qui utilise la BDD en question, n'a aucun problème de lenteur, bien qu'il fasse des requêtes bien plus complexes et nombreuses.
Notez que l'application n'étant pas utilisable avec cette lenteur, elle n'a pas était utilisé depuis bien plus d'une semaine, elle n'est pas en cause des redémarrages.
Merci pour votre proposition de passer sur une offre supérieure, mais je veux être sûr ET garantis que cela solutionnerait le problème avant d'upgrader notre abonnement !
J'ai créé un ticket pour avoir accès au log de la BDD (Les logs n'étant pas visibles sur l'espace perso + aucun moyen de me connecter en SFTP pour récupérer stdout.log, on ne sait pas pourquoi.
Merci
Bonjour a tous,
Je suis d'accord avec @janus57 sur le probleme de la latence, une base de données peut repondre a une requete en moins d'une miliseconde, du coup quand on rajoute 20ms a chaque requetes, ça peut vite faire exploser le temps de reponse globale. C'est pour cette raison qu'il faut toujours avoir sa base de données au plus proche de son application. (Dans ton cas si l'application etait hebergée sur le serveur du Prestashop, ça marcherai surement beaucoup mieux)
Ensuite j'ai regardé les requetes, les 3 premieres pourraient etre combinées en une seule, la 4eme te renvoit plus de 7800 lignes pour que tu ne prennes que la premiere (au hasard du coup). Difficile de diagnostiquer quelque chose avec cet "extract" des requetes 
Il faudrait que tu arrive a timer chacune des requetes qui partent de ton serveur pour voir ce qu'il se passe vraiment, lesquels vont bien, lesquels non et identifier vraiment un probleme.
En esperant avoir repondu a quelques interrogations 