Bonjour à tous,
depuis hier après-midi, mon site (https://www.ramdam-dlx.com), créé avec Wordpress et hébergé en Cloud Web 1, est inaccessible. J'ai d'abord été notifié par Jetpack le 23/04 à 14h34 que mon site ne chargeait pas, puis une notification de retour à la normale à 14h45.
Je n'ai pris connaissance de ces mails qu'en fait de journée, et j'ai tenté d'accéder à mon site dans la foulée. Depuis, il reste désespérément injoignable, affichant en permanence une erreur 504 (soit une page blanche avec "504 Gateway Time-out / nginx", soit la page OVH "Error 504: Backend unavailable").
Je n'ai de mon côté rien modifié à mon site dans la journée d'hier. J'ai ouvert un ticket (#1091389775)
Je constate dans l'outil de suivi des travaux et incidents d'OVH qu'un incident Cloud est en cours depuis hier (23/04) à 14h48, sans aucune résolution.
Par quel moyen puis-je vérifier si c'est bien ce qui rend mon site indisponible ?
Si c'est le cas, dans quels délais peut-on espérer une résolution ? Cela fait bientôt 24h que l'incident a débuté, ce qui semble exceptionnellement long.
Si ce n'est pas le cas, que puis-je mettre en œuvre pour résoudre le problème de mon côté ?
Merci d'avance pour vos réponses 
> exceptionnellement long
ça paraît le normal chez Ovh pour un mutu, voir dans la catégorie hébergement web, le cluster27, lundi/mardi
tu ne peux rien faire, tu dépends de ton hébergeur
Bonjour,
je transmets à l'équipe en charge.
Cordialement AntoineB1
Salut @BaptisteD7
Actuellement ton site est joignable, mais est extrêmement long à répondre.
> Je constate dans l'outil de suivi des travaux et incidents d'OVH qu'un incident Cloud est en cours depuis hier (23/04) à 14h48, sans aucune résolution.
Cet incident Cloud n'est pas lié à ton problème. Si tu regardes si la page http://travaux.ovh.net">travaux > Cloud, tu peux voir la région concerné par l'incident (`WAW1`, `GRA1`, `SBG3` etc.)
Les hébergements Cloud Web sont eux dans une région dédiés (dans le DC de Gravelines) appelé `INTERNAL.GRA1`. Donc tant que tu ne vois pas sur un incident donné, ce n'est pas lié
> J'ai d'abord été notifié par Jetpack le 23/04 à 14h34 que mon site ne chargeait pas, puis une notification de retour à la normale à 14h45.
Je constate sur ton hébergement une très forte charge côté CPU/RAM le 23/04 de ~14h20 à 14h40. Idem le 22/04 de ~16h50 à 17h50.
Pour ce qui est des dernières 24h la charge CPU/RAM est assez basse (cf l'image ci-jointe, attention les heures sont en UTC donc rajoute +2h pour avoir l'heure française), donc ce n'est pas la source des lenteurs de ton site.
> ça paraît le normal chez Ovh pour un mutu, voir dans la catégorie hébergement web, le cluster27, lundi/mardi
Cet hébergement est sur cluster024, donc pas lié aux éventuels problèmes sur cluster027.
> il reste désespérément injoignable, affichant en permanence une erreur 504 (soit une page blanche avec "504 Gateway Time-out / nginx", soit la page OVH "Error 504: Backend unavailable").
Cette erreur 504 est renvoyé quand ton site ou un élément de ton site est très/trop long à répondre. As-tu essayé de regarder avec ton navigateur (Firefox, Chrome ou autre), en utilisant la console de développeur, pour identifier ce qui met du temps à répondre ? Quand j'essaye de mon côté, je vois que systématiquement une requete met très (très) longtemps à répondre:
```
https://www.ramdam-dlx.com/?custom-css=86352c779a
```
A chaque première requete cette page met + de 6min à répondre (360000ms). Elle tombe très souvent en timeout, créant des erreurs 504 (cf autre PJ). Essaye de charger plusieurs fois cette page de suite, tu devrais avoir le même comportement.
Je pense que ton problème vient de là.
Donc à première vue le problème ne vient pas du Cloud Web mais du code côté Wordpress. Soit tes assets compilés sont en erreur, soit tu utilises un thème/plugin mal codé ou mal configuré.
Je te laisse regarder cette histoire de `?custom-css=86352c779a` et revenir vers moi quand tu auras + d'info
Pierre
Merci pour ta réponse.
Je suis designer plus qu'autre chose et c'est pour ça que je n'ai pas su trouver toutes ces précieuses informations moi-même. Merci beaucoup !
Ce qui m'alerte, c'est que ce problème est apparu soudain alors qu'aucune intervention n'a été réalisée sur le backoffice.
Avec la console développeur, je n'arrive pas à reproduire les résultats que tu obtiens (de mon côté, ça ne charge tout bonnement rien à part le favicon).
Le custom-css pourrait provenir de Jetpack, si je me base sur les plugins que j'utilise. La seule fonction d'ajout de CSS que j'ai utilisée est celle proposée dans Wordpress > Apparence > Personnaliser > CSS additionnel. Or, sans accès à mon interface administrateur (du fait que mon site ne répond pas), je suis incapable de désactiver quoi que ce soit pour voir si l'erreur disparaît.
Je suis un peu perdu compte tenu de mon manque de connaissance et la situation m'inquiète grandement.
encore un site à optimiser, décidément, Ovh les attirent les sites à optimiser<br /><br /><br />> Je te laisse regarder cette histoire de ?custom-css=86352c779a<br /><br />depuis quand un css bloquerait un chargement?<br /><br />https://i.imgur.com/0jyv6h2.png<br /><br />vois tu un début de téléchargement ?<br /><br />ça vous arrive de croire les gens et de tester de l'extérieur?<br />```text<br />time wget -p https://www.ramdam-dlx.com/<br />--2019-04-24 16:56:20-- https://www.ramdam-dlx.com/<br />Résolution de www.ramdam-dlx.com (www.ramdam-dlx.com)… 213.186.33.187<br />Connexion à www.ramdam-dlx.com (www.ramdam-dlx.com)|213.186.33.187|:443… connecté.<br />requête HTTP transmise, en attente de la réponse… 503 Backend unavailable<br />2019-04-24 16:58:50 erreur 503 : Backend unavailable.<br /><br /><br />real 2m30,140s<br /><br />curl --head -XGET --user-agent firefox https://www.ramdam-dlx.com/<br /> HTTP/2 504 <br /> date: Wed, 24 Apr 2019 14:54:38 GMT<br /> content-type: text/html<br /> content-length: 176<br />```<br /><br />même pas d'entêtes complets.... c'est worpdress bien sûr !<br /><br />```text<br />dig +nocmd +noall +answer www.ramdam-dlx.com A @dns112.ovh.net<br /> www.ramdam-dlx.com. 3600 IN A 213.186.33.187<br /> dig +short -x 213.186.33.187 -> full-cdn-01.cluster024.hosting.ovh.net<br />```<br />ah tiens un CDN à passer en plus...
À part que je suis un neuneu, je ne comprends rien à votre message @kyodev. Votre intervention manque de tact (et de clarté compte tenu de mon profil) et je vous avoue que c'est démoralisant quand on est absolument désemparé comme je le suis – après toute l'énergie que j'ai investie dans la création de mon site. Il y a un humain de l'autre côté de la conversation.
Mais je suis bien obligé de vous remercier d'avoir pris de votre temps pour regarder cela.
J'ai fait attention à utiliser un thème et des plugins aussi fiables que possible, et j'ai notamment fait l'acquisition de WP Rocket pour optimiser mon site. Ce n'est sans doute pas suffisant compte tenu du problème que je rencontre depuis hier, mais c'est aussi le principe d'un CMS comme Wordpress me semble-t-il, de rendre accessible la création d'un site web au plus grand nombre.
Le CDN est celui activé sur mon offre d'hébergement cloud. Présente-t-il un problème ?
EDIT : je constate que la mention "neuneu" a été retirée de votre message initial.
oui, j'ai retiré pour que cela ne soit pas mal interprété… 
c'est une réaction colérique envers le support qui ne sait répondre que ça, sans se préoccuper de pourquoi les gens se plaignent, et se mettre dans des conditions RÉELLES de test
donc @BaptisteD7, moi je ne te prends pas pour un con, je sais que tu as des soucis et en plus tu es sur une offre la plus lente que j'ai pu constaté chez Ovh
reste à attendre les réponses
lundi matin alors que clairement dit que c'était un souci de serveur, le support aussi a sorti son sempiternel optimisation à faire… jusqu'au soir où le discours a changé et le lendemain matin ou le souci résolu, 24 h après, sans explications
voilà pour le cluster27… bien sûr, il est évident que je ne savais pas faire la différence
tu as bien bossé baptiste?<br />sur une quinzaine d'essais, je vois que ton site est réapparu :)<br />```text<br />curl --head -XGET --user-agent firefox https://www.ramdam-dlx.com/<br /> HTTP/2 200 <br /> date: Wed, 24 Apr 2019 16:35:42 GMT<br /> content-type: text/html; charset=UTF-8<br /> expires: Wed, 24 Apr 2019 16:35:41 GMT<br /> x-cdn-pop: rbx1<br /> x-cdn-pop-ip: 51.254.41.192/26<br /> x-cacheable: Cacheable<br />```<br /><br />`DOMContentLoaded: 3,85 s load: 5,96 s`<br />même s'il manque <br />https://www.ramdam-dlx.com/wp-json/mailchimp-for-woocommerce/v1/queue/work<br /><br />on peut surfer, félicitations, tu as bien bossé
C'est donc revenu tout seul. Inadmissible de devoir subir quasiment 30h d'interruption de service sans aucune réponse pertinente de la part du service technique.
ah bon, moi qui croyais que tu avais bossé 
Bon, hé bien ça a sauté de nouveau…
Est-ce que le support OVH peut me tenir informé au plus vite, ça commence à faire beaucoup
Eeeeeeet retour à la normale.
Vivent les montagnes russes.
Mon site met désormais un temps fou à charger !!! Je commence à en avoir ma claque, pas une réponse du support sur mon ticket ni sur cette conversation. Que faut-il faire pour avoir un service QUI FONCTIONNE ?!?! @PierreFr
Pendant ce temps-là, je continue à payer pour cet hébergement instable et mes campagnes de publicité en ligne me coûtent de l'argent pour rien puisqu'elles renvoient vers un site inaccessible.
OVH, sortez-vous les doigts et donnez-moi des réponses, scrogneugneu !
les réponses Ovh, aussi rapide que les perfs d'un *"cloud web"*... <br /> https://community.ovhcloud.com/t/43309<br /><br /><br />je révisais mon script, je t'avais mis dans le lot:<br />```text<br />25/04/2019 23:10:46 +0200 0 mn 44,646 s<br />25/04/2019 23:15:44 +0200 0 mn 42,482 s<br />25/04/2019 23:20:45 +0200 0 mn 43,381 s<br />25/04/2019 23:25:47 +0200 0 mn 46,428 s<br />25/04/2019 23:30:47 +0200 0 mn 45,649 s<br />25/04/2019 23:40:41 +0200 0 mn 40,027 s<br />25/04/2019 23:45:55 +0200 0 mn 40,881 s<br />25/04/2019 23:50:54 +0200 0 mn 39,646 s<br />...<br />26/04/2019 13:35:50 +0200 0 mn 39,598 s<br />26/04/2019 13:40:54 +0200 0 mn 39,564 s<br />26/04/2019 13:45:56 +0200 0 mn 39,208 s<br />26/04/2019 13:50:54 +0200 0 mn 38,639 s<br />26/04/2019 13:55:46 +0200 0 mn 40,594 s<br />26/04/2019 14:04:41 +0200 4 mn 26,244 s<br />26/04/2019 14:06:46 +0200 1 mn 30,067 s<br />26/04/2019 14:10:49 +0200 0 mn 39,127 s<br />26/04/2019 14:15:54 +0200 0 mn 43,483 s<br />26/04/2019 14:26:52 +0200 1 mn 37,145 s<br />26/04/2019 14:32:04 +0200 11 mn 50,090 s<br />26/04/2019 14:32:45 +0200 2 mn 30,172 s<br />26/04/2019 14:39:00 +0200 3 mn 46,202 s<br />26/04/2019 14:42:53 +0200 2 mn 39,361 s<br />26/04/2019 14:46:13 +0200 0 mn 58,274 s<br />26/04/2019 14:51:20 +0200 1 mn 5,837 s<br />26/04/2019 14:56:18 +0200 1 mn 3,050 s<br />```<br /><br />40s étant le nominal<br />inutile de parler d'optimisation, pas de cache, je charge tout, même le delayed
@PierreFr, je ne sais plus quoi faire : tous les jours, 1h30 à 2h de coupure minimum, le service technique est injoignable par téléphone, mon site est la pierre angulaire de mon activité et l'hébergement ne tient pas du tout ses promesses.
Est-il possible d'identifier l'origine du problème et m'aider à y apporter une résolution ?
Bonjour,
cela fait plusieurs fois que je viens sur ton post et je n'ai jamais rencontré l'erreur 504.
Apparemment tu n'as le problème que lorsque tu es connecté à ton site.
Il y a peut-être un plugin qui pose problème.
Essayes de les désactiver.
Est-ce que l'erreur apparaît après certaines manipulations comme créer un article, uploadé une image etc. ?
```
+-------------------------------------------+
| Ton container cloudwen |
Requête client | |
depuis ----> Passerelle NGINX —> | Apache2 —> PHP qui va exécuter ton |
son navigateur 60 sec | script wordpress |
+-------------------------------------------+
```
L'erreur 504 vient du site qui met trop de temps à répondre (+ de 60 sec).
Par exemple :
- si ton site se connecte à une base de données et que celle-ci met beaucoup de temps à répondre (+ de 60 sec) alors Nginx ne va pas attendre plus longtemps et retourner 504 Timeout au client.
- si wordpress accède à des ressources externes à ton site et que ces ressources externes sont lentes à répondre => idem 504.
Tu peux essayer de mettre un timeout plus faible dans PHP en ajoutant cette ligne dans ton index.php au début du fichier juste après la balise "```
ini_set('default_socket_timeout', 5); //(valeur par défaut: 60 sec)
```
De cette façon si le problème est lié à des ressources externes au site qui pose problème alors php partira en timeout avant nginx et c'est php qui te retournera un timeout.
Par contre pour voir ce que te retourne php, il faut activer l'affichage des erreurs PHP. Pour ce faire il faut passer par le panel OVH et passer ton PHP en "développement".
Par contre si c'est ton script wordpress qui bug avec une boucle infini, ou tout autre problème, alors l'action ci-dessus n'aura aucun effet. Tu peux alors essayer de désactiver les plugins un par un. En renommant les dossiers de chaque plugins. Ceux-ci se trouve dans le dossier wp-contents/plugins/
si par exemple tu as un plugins "articles" tu le renommes en "articles.dis" (dis pour disabled)
Autres chose à savoir, lorsque tu accèdes à ton site une session PHP est ouverte et est associé à ton navigateur via un cookie de session.
Si par exemple ton script PHP wordpress met du temps à traiter la requête client (ça tourne dans le vide) et que tu fait F5) ton script PHP ne va traiter le nouvelle requête demandée, il va chercher à terminer la requête précédente pour libérer la session avant de traiter la nouvelle requête.
Ce que tu peux faire à ce moment là c'est de tester avec un autre navigateur ou alors de tester en navigation privée, ce qui va avoir pour effet de créer une nouvelle session PHP ( car l'autre est bloquée )
Bien entendu cela finira par se débloquer tout seul car PHP a un timeout (ça doit être dans les 300 à 400 secondes sur OVH)
Cela peut expliquer le fait que tu te retrouves bloqué pendant plusieurs dizaines de minutes sur l'erreur 504.
Par exemple tu accède à ton site, le script tourne en boucle, tu fais F5, la nouvelle requête est mise en attente, tu refais F5 et la 3ème requête est mise en file derrière la requête 2 etc.
Dans tous les cas les problèmes de timeout ne sont pas toujours évident à régler pour un CMS, surtout si beaucoup de plugins sont présents, mutipliant les sources potentielles de problèmes.
Dans certains cas les erreurs 504 son liées à OVH, si par exemple leur serveurs rament mais je ne pense pas dans ton cas que cela soit ça.
Cordialement,
Boris.
décidemment…
un extrait:
```text
27/04/2019 13:56:12 +0200 0 mn 55,744 s
27/04/2019 14:01:13 +0200 0 mn 56,650 s
27/04/2019 14:06:08 +0200 0 mn 55,991 s
27/04/2019 14:11:11 +0200 0 mn 57,108 s
27/04/2019 14:16:11 +0200 0 mn 55,928 s
27/04/2019 14:21:55 +0200 1 mn 40,264 s !
27/04/2019 14:32:47 +0200 2 mn 30,119 s !!
27/04/2019 14:37:36 +0200 2 mn 30,113 s !!
27/04/2019 14:41:10 +0200 16 mn 4,417 s !!!
27/04/2019 14:42:44 +0200 2 mn 30,105 s !!
27/04/2019 14:47:44 +0200 2 mn 30,124 s !!
27/04/2019 14:52:45 +0200 2 mn 30,123 s !!
27/04/2019 14:57:44 +0200 2 mn 30,128 s !!
27/04/2019 15:02:45 +0200 2 mn 30,115 s !!
27/04/2019 15:07:44 +0200 2 mn 30,123 s !!
27/04/2019 15:12:46 +0200 2 mn 30,178 s !!
27/04/2019 15:17:40 +0200 2 mn 30,116 s !!
27/04/2019 15:22:45 +0200 2 mn 30,123 s !!
27/04/2019 15:27:36 +0200 2 mn 30,123 s !!
27/04/2019 15:32:44 +0200 2 mn 30,113 s !!
27/04/2019 15:37:37 +0200 2 mn 30,120 s !!
27/04/2019 15:42:45 +0200 2 mn 30,119 s !!
27/04/2019 15:47:44 +0200 2 mn 30,129 s !!
27/04/2019 15:52:41 +0200 2 mn 30,112 s !!
27/04/2019 15:57:49 +0200 2 mn 30,132 s !!
27/04/2019 16:02:46 +0200 2 mn 30,106 s !!
27/04/2019 16:07:40 +0200 2 mn 30,126 s !!
27/04/2019 16:13:19 +0200 3 mn 7,765 s !!!
27/04/2019 16:16:11 +0200 0 mn 56,010 s
27/04/2019 16:21:08 +0200 0 mn 57,106 s
27/04/2019 16:26:14 +0200 0 mn 58,025 s
27/04/2019 16:31:12 +0200 0 mn 55,439 s
27/04/2019 16:36:18 +0200 1 mn 0,342 s !
27/04/2019 16:41:10 +0200 0 mn 58,853 s
27/04/2019 16:46:09 +0200 0 mn 58,929 s
27/04/2019 16:51:10 +0200 0 mn 59,142 s
27/04/2019 16:56:18 +0200 1 mn 3,838 s !
27/04/2019 17:01:29 +0200 1 mn 11,250 s !
27/04/2019 17:06:25 +0200 1 mn 10,025 s !
27/04/2019 17:11:20 +0200 1 mn 5,007 s !
27/04/2019 17:16:29 +0200 1 mn 12,390 s !
27/04/2019 17:21:13 +0200 1 mn 5,857 s !
27/04/2019 17:26:27 +0200 1 mn 11,516 s !
27/04/2019 17:31:27 +0200 1 mn 11,781 s !
27/04/2019 17:36:14 +0200 0 mn 59,037 s
27/04/2019 17:41:14 +0200 0 mn 58,034 s
27/04/2019 17:46:12 +0200 0 mn 56,532 s
27/04/2019 17:51:29 +0200 0 mn 58,203 s
27/04/2019 17:56:10 +0200 1 mn 0,966 s !
27/04/2019 18:01:10 +0200 0 mn 57,723 s
27/04/2019 18:06:16 +0200 0 mn 59,211 s
27/04/2019 18:11:01 +0200 0 mn 55,244 s
27/04/2019 18:16:23 +0200 1 mn 6,900 s !
27/04/2019 18:21:20 +0200 1 mn 2,164 s !
27/04/2019 18:26:16 +0200 0 mn 57,703 s
27/04/2019 18:31:08 +0200 0 mn 59,634 s
27/04/2019 18:36:13 +0200 0 mn 56,966 s
27/04/2019 18:41:09 +0200 0 mn 55,280 s
27/04/2019 18:46:13 +0200 0 mn 58,251 s
27/04/2019 18:51:10 +0200 1 mn 0,089 s !
27/04/2019 21:01:19 +0200 1 mn 3,708 s !
27/04/2019 21:06:10 +0200 0 mn 59,801 s
27/04/2019 21:16:18 +0200 1 mn 2,837 s !
27/04/2019 21:21:13 +0200 0 mn 58,419 s
27/04/2019 21:26:28 +0200 1 mn 17,219 s !
27/04/2019 21:31:31 +0200 1 mn 20,063 s !
27/04/2019 21:36:29 +0200 1 mn 22,495 s !
27/04/2019 21:41:50 +0200 1 mn 35,055 s !
27/04/2019 21:47:00 +0200 1 mn 45,189 s !
27/04/2019 21:52:14 +0200 1 mn 58,978 s !
27/04/2019 21:58:05 +0200 2 mn 49,255 s !!
27/04/2019 22:04:56 +0200 4 mn 45,018 s !!!
27/04/2019 22:09:51 +0200 4 mn 34,583 s !!!
27/04/2019 22:11:14 +0200 0 mn 58,620 s
27/04/2019 22:16:07 +0200 0 mn 51,924 s
27/04/2019 22:21:08 +0200 0 mn 55,283 s
27/04/2019 22:26:09 +0200 0 mn 54,134 s
27/04/2019 22:31:15 +0200 0 mn 59,371 s
27/04/2019 22:36:09 +0200 0 mn 56,158 s
27/04/2019 22:41:14 +0200 1 mn 2,764 s !
27/04/2019 22:46:19 +0200 1 mn 4,556 s !
27/04/2019 22:51:09 +0200 1 mn 1,584 s !
27/04/2019 22:56:18 +0200 1 mn 4,159 s !
27/04/2019 23:01:18 +0200 1 mn 3,160 s !
27/04/2019 23:06:11 +0200 0 mn 55,883 s
27/04/2019 23:11:11 +0200 0 mn 54,460 s
27/04/2019 23:16:12 +0200 0 mn 58,257 s
27/04/2019 23:21:12 +0200 0 mn 58,184 s
27/04/2019 23:26:25 +0200 1 mn 11,066 s !
27/04/2019 23:31:13 +0200 1 mn 2,364 s !
27/04/2019 23:36:20 +0200 1 mn 6,006 s !
27/04/2019 23:41:07 +0200 0 mn 56,624 s
27/04/2019 23:46:11 +0200 0 mn 57,277 s
27/04/2019 23:51:11 +0200 0 mn 54,128 s
27/04/2019 23:56:20 +0200 1 mn 2,386 s !
28/04/2019 00:01:08 +0200 0 mn 53,149 s
28/04/2019 05:36:27 +0200 1 mn 9,426 s !
28/04/2019 05:41:33 +0200 1 mn 19,152 s !
28/04/2019 05:46:31 +0200 1 mn 17,269 s !
28/04/2019 05:51:15 +0200 1 mn 4,193 s !
28/04/2019 05:56:10 +0200 1 mn 4,848 s !
28/04/2019 06:01:25 +0200 1 mn 9,745 s !
28/04/2019 06:06:19 +0200 1 mn 4,434 s !
28/04/2019 06:11:17 +0200 1 mn 3,393 s !
28/04/2019 06:16:16 +0200 1 mn 4,314 s !
28/04/2019 06:21:18 +0200 1 mn 3,573 s !
28/04/2019 06:26:16 +0200 1 mn 5,601 s !
28/04/2019 06:31:12 +0200 0 mn 56,203 s
28/04/2019 06:36:13 +0200 0 mn 58,645 s
28/04/2019 06:41:17 +0200 1 mn 6,982 s !
28/04/2019 06:46:16 +0200 1 mn 1,854 s !
28/04/2019 06:51:27 +0200 1 mn 16,164 s !
28/04/2019 06:56:14 +0200 1 mn 1,076 s !
28/04/2019 07:01:20 +0200 1 mn 4,065 s !
28/04/2019 07:06:18 +0200 1 mn 3,849 s !
28/04/2019 07:11:12 +0200 1 mn 0,485 s !
```
le nominal est à 40s / 50s, Baptiste sait pourquoi (en privé)
donc non, rien de spécial n'est fait
ce sont des performance normales d'un cloudWeb
Baptiste sait pourquoi (en privé)
C'est à dire ? la source du problème est identifiée ?