bonjour,
depuis l'incident de lundi (pourtant cloturé) ici : http://travaux.ovh.net/?do=details&id=34701&PHPSESSID=eb14c864fa36f49769b7f019d0beaac3 les membres de mon forum se plaigent de lenteurs...
Et effectivement, si j'analyse l'acitivité de l'hébergement, il y a un temps de réponse SQL anormale depuis l'incident :
Est-ce qe cela va être corrigé par OVH ou bien je dois faire quelque chose de mon coté pour rétablir la situation ?
Merci de votre aide
Lenteur site depuis crash OVH du 15 octobre
Related questions
- [RESOLU] Server unable to read htaccess file, denying access to be safe
64931 
24.11.2019 19:11
- Version php 7.0 sur Ovh mais php 5.4.45 sur mon wordpress
59531 10.01.2019 11:14
- Effacer wordpress d'OVH et reinstaller
59316 08.09.2019 21:02
- Comment récupérer son mot de passe phpmyadmin ?
57825 14.11.2016 10:32
- Changer la version d'une base de donnée en mutualisé
55988 22.12.2016 11:46
- Ne supporte pas FTP sur TLS
54527 11.12.2018 18:48
- Résiliation hébergement
54395 27.07.2018 10:39
- Variable upload_max_filesize plus grande que post_max_size
50172 11.06.2017 16:01
- Résiliation hébergement+domaine
48680 11.09.2018 20:28
- Transfert hebergement et domaine .fr entre client OVH ?
47052 21.12.2016 15:10
Bonjour,
Pourriez-vous me préciser le domaine s'il vous plaît ? Je vais regarder.
ThT
Bonjour Th.t,
binano.fr
Merci
Effectivement il y a eu l'incident le jour où vos temps de réponse SQL ont augmenté sur vos metrics, mais je crains que ce ne soit surtout l'utilisation de cette bdd qui pose probleme.
Par exemple votre base de données 001 à reçu 1 400 000 requêtes ces dernières 24h (1.2M pour la 005), ce qui est trop avec ou sans l'incident, une base d'hébergement ne peut tenir cette charge avec un comportement normal. Une base sur un SQL Privé serait plus adaptée, d'autant que vous avez beaucoup de bases dont certaines en extra de votre hébergement, que vous pourriez migrer et centraliser sur le SQL Privé, plus performant avec une RAM dédiée. En passant sur un hébergement Performance (SQL Privé inclut) par exemple.
Je vous invite a tester un benchmark dans PhPMyAdmin pour vous rendre compte du vrai temps de réponse de celle ci (sans faire appel à un script donc). On en parle ici : https://www.webrankinfo.com/forum/t/benchmark-de-ses-requetes-sql.94502/
Bonne journée,
ThT
Merci, j'ai déjà testé un SQL privé il y a quelques années et ce fut une catastrophe.
Permettez moi donc d'insister car tout fonctionnait parfaitement avant le crash de lundi. De plus, vous m'annoncez 1,2M de requêtes pour la 005 mais cela est impossible car c'est la base de données d'un forum qui est quasiment abandonné. J'ai 5 autres forum avec exactement la même architecture qui ne posent aucun problème.
Sans vouloir abuser de votre temps, pourriez-vous, s'il vous plait, explorer la piste suivante ? : Il y a quelques fois des fichiers temporaires générés par MySQL qui ne sont pas effacés. Ca m'est arrivé 2 fois sur cette base, en 2005 et en 2017. GuillaumeL : https://community.ovh.com/u/guillaumel/summary avait résolu mon problème en supprimant ces fichiers temporaires. Cela ne viendrait-il pas de la même chose ?
La réponse des autres techniciens étaient la même que la votre à l'époque...
Après une réparation/optimisation de la base de données, cela semble être rentré dans l'ordre... A confirmer en charge dans la journée demain
