504 Gateway Timeout depuis bientôt 24h

> 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.

```text encore un site à optimiser, décidément, Ovh les attirent les sites à optimiser


> Je te laisse regarder cette histoire de ?custom-css=86352c779a

depuis quand un css bloquerait un chargement?

https://i.imgur.com/0jyv6h2.png

vois tu un début de téléchargement ?

ça vous arrive de croire les gens et de tester de l'extérieur?
```text
time wget -p https://www.ramdam-dlx.com/
--2019-04-24 16:56:20-- https://www.ramdam-dlx.com/
Résolution de www.ramdam-dlx.com (www.ramdam-dlx.com)… 213.186.33.187
Connexion à www.ramdam-dlx.com (www.ramdam-dlx.com)|213.186.33.187|:443… connecté.
requête HTTP transmise, en attente de la réponse… 503 Backend unavailable
2019-04-24 16:58:50 erreur 503 : Backend unavailable.


real 2m30,140s

curl --head -XGET --user-agent firefox https://www.ramdam-dlx.com/
HTTP/2 504
date: Wed, 24 Apr 2019 14:54:38 GMT
content-type: text/html
content-length: 176
```

même pas d'entêtes complets.... c'est worpdress bien sûr !

```text
dig +nocmd +noall +answer www.ramdam-dlx.com A @dns112.ovh.net
www.ramdam-dlx.com. 3600 IN A 213.186.33.187
dig +short -x 213.186.33.187 -> full-cdn-01.cluster024.hosting.ovh.net
```
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

```text tu as bien bossé baptiste?
sur une quinzaine d'essais, je vois que ton site est réapparu :)
```text
curl --head -XGET --user-agent firefox https://www.ramdam-dlx.com/
HTTP/2 200
date: Wed, 24 Apr 2019 16:35:42 GMT
content-type: text/html; charset=UTF-8
expires: Wed, 24 Apr 2019 16:35:41 GMT
x-cdn-pop: rbx1
x-cdn-pop-ip: 51.254.41.192/26
x-cacheable: Cacheable
```

`DOMContentLoaded: 3,85 s load: 5,96 s`
même s'il manque
https://www.ramdam-dlx.com/wp-json/mailchimp-for-woocommerce/v1/queue/work

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 !

```text les réponses Ovh, aussi rapide que les perfs d'un *"cloud web"*...
https://community.ovhcloud.com/community/fr/transfert-de-site-d-un-mutu-vers-un-cloud-web?id=community_question&sys_id=a9d1310081928210f0780f07683eb214


je révisais mon script, je t'avais mis dans le lot:
```text
25/04/2019 23:10:46 +0200 0 mn 44,646 s
25/04/2019 23:15:44 +0200 0 mn 42,482 s
25/04/2019 23:20:45 +0200 0 mn 43,381 s
25/04/2019 23:25:47 +0200 0 mn 46,428 s
25/04/2019 23:30:47 +0200 0 mn 45,649 s
25/04/2019 23:40:41 +0200 0 mn 40,027 s
25/04/2019 23:45:55 +0200 0 mn 40,881 s
25/04/2019 23:50:54 +0200 0 mn 39,646 s
...
26/04/2019 13:35:50 +0200 0 mn 39,598 s
26/04/2019 13:40:54 +0200 0 mn 39,564 s
26/04/2019 13:45:56 +0200 0 mn 39,208 s
26/04/2019 13:50:54 +0200 0 mn 38,639 s
26/04/2019 13:55:46 +0200 0 mn 40,594 s
26/04/2019 14:04:41 +0200 4 mn 26,244 s
26/04/2019 14:06:46 +0200 1 mn 30,067 s
26/04/2019 14:10:49 +0200 0 mn 39,127 s
26/04/2019 14:15:54 +0200 0 mn 43,483 s
26/04/2019 14:26:52 +0200 1 mn 37,145 s
26/04/2019 14:32:04 +0200 11 mn 50,090 s
26/04/2019 14:32:45 +0200 2 mn 30,172 s
26/04/2019 14:39:00 +0200 3 mn 46,202 s
26/04/2019 14:42:53 +0200 2 mn 39,361 s
26/04/2019 14:46:13 +0200 0 mn 58,274 s
26/04/2019 14:51:20 +0200 1 mn 5,837 s
26/04/2019 14:56:18 +0200 1 mn 3,050 s
```

40s étant le nominal
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é)

on sait pourquoi le nominal est haut (40 à 50s)
mais cela n'explique pas les variation, jusqu'à 16mn !!...
très souvent 1 à 2 mn

perso, moi je subodore la cause, et ça ne serait pas une première, surtout sur un cloudWeb

par exemple
```text
29/04/2019 04:02:17 +0200 2 mn 3,305 s !!
29/04/2019 04:06:49 +0200 1 mn 35,636 s !
29/04/2019 04:11:54 +0200 1 mn 40,445 s !
29/04/2019 04:17:05 +0200 1 mn 54,609 s !
29/04/2019 04:23:46 +0200 3 mn 32,558 s !!!
29/04/2019 04:26:10 +0200 0 mn 53,727 s
29/04/2019 04:32:01 +0200 1 mn 48,361 s !
29/04/2019 04:37:13 +0200 2 mn 1,458 s !
29/04/2019 04:42:05 +0200 1 mn 50,265 s !
29/04/2019 04:46:05 +0200 0 mn 54,133 s
29/04/2019 04:52:34 +0200 2 mn 17,842 s !!
29/04/2019 04:57:21 +0200 2 mn 6,504 s !!
29/04/2019 05:02:22 +0200 2 mn 7,421 s !!
29/04/2019 05:05:23 +0200 0 mn 7,680 s échec
29/04/2019 05:10:58 +0200 0 mn 44,828 s
29/04/2019 05:15:56 +0200 0 mn 42,292 s
29/04/2019 05:20:59 +0200 0 mn 47,116 s
29/04/2019 05:26:06 +0200 0 mn 52,793 s
29/04/2019 05:31:05 +0200 0 mn 50,669 s
29/04/2019 05:36:00 +0200 0 mn 46,526 s
29/04/2019 05:43:53 +0200 3 mn 39,015 s !!!
29/04/2019 05:46:04 +0200 0 mn 50,316 s
29/04/2019 05:51:17 +0200 1 mn 3,822 s !
29/04/2019 06:01:01 +0200 5 mn 50,127 s !!!!!
29/04/2019 06:02:50 +0200 2 mn 34,961 s !!
29/04/2019 06:05:14 +0200 0 mn 1,953 s échec
29/04/2019 06:10:15 +0200 0 mn 0,092 s échec
29/04/2019 06:15:15 +0200 0 mn 0,091 s échec
29/04/2019 06:20:07 +0200 0 mn 0,093 s échec
29/04/2019 06:26:59 +0200 1 mn 45,740 s !
29/04/2019 06:31:59 +0200 1 mn 44,312 s !
```
7s ou moins d'une seconde, aussi rapide...
ça pue le 504 :/

Bonjour @BaptisteD7

On a investigué un peu plus sur tes erreurs, ça semble venir des crons (tâche périodique) WordPress qui viennent remplir entièrement le pool de connexion PHP, et bloquer toute nouvelles connexions.

Quand tes crons WordPress ont remplis toutes les connexions possible côté PHP-FPM, et que tu essayes d'accéder à ton site via ton navigateur, PHP ne peut plus prendre de nouvelle connexion et t'affiche un 504 quand le timeout est atteind.
Et ça ressemble bien à ce que décrit @BorisM.

Cet après-midi le problème s'est de nouveau produit (vers ~15h10). Au moment où ton site était bloqué, **toutes** les connexions du pool PHP-FPM ressemblaient à ça:

```
************************
pid: 299
state: Finishing
start time: 30/Apr/2019:15:19:43 +0200
start since: 23
requests: 3
request duration: 21180305
request method: POST
request URI: /wp-cron.php?doing_wp_cron=1556630385.7218189239501953125000
content length: 0
user: -
script: /home/ramdami/www/wp-cron.php
last request cpu: 0.00
last request memory: 0
```
Au bout d'un certain temps ces connexions vers `wp-cron.php` bloqué en statut `Finishing` sont killé par PHP, ce qui rend le site de nouveau accessible. Ça expliquerait pourquoi le problème à lieu de façon périodique et pas en permanence.

Quand je regarde les crons configurées sur ton WordPress, la plupart viennent de plugins.
Je te conseil donc d'y jeter un oeil et de vérifier si toutes les crons activés par les plugins sont bien nécessaires.
Tu peux aussi, pour valider cette hypothèse comme quoi le problème vient bien des crons WordPress, désactiver les crons pour une durée déterminé (quelques heures; une journée) et voir si le problème se produit pendant ce laps de temps. Si pas de problème de 504 quand les crons sont désactivé, c'est que c'est bien la source du problème.

Dernier conseil, regarde si tu peux te passer du plugin "https://wordpress.org/plugins/mailchimp-for-woocommerce/#reviews `mailchimp-for-woocommerce`" qui semble faire + de mal que de bien (cf les reviews du plugin et les erreurs précédemment constaté sur https://www.ramdam-dlx.com/wp-json/mailchimp-for-woocommerce/v1/queue/workhttps://www.1dlx.com/wp-json/mailchimp-for-woocommerce/v1/queue/workdlx.com/wp-json/mailchimp-for-woocommerce/v1/queue/work quand le site va bien.

Je te laisses essayer ça de ton côté et revenir vers nous pour nous dire ce que ça donne

le site est en rade **depuis hier soir** et vient de m'afficher le contenu de wp-config.php.. !!
ça craint..

LE MOT DE PASSE DE LA BASE sera à changer

mailchimp, oui bof
désactiver le cron, dans wp-config:
```php
// désactivation wp-cron
define('DISABLE_WP_CRON', true);
```

c'est temporaire ou éventuellement, activer le cron Ovh sur `/wp-cron.php`, mais ça va pas plaire à certains plugins

Merci pour vos réponses. Je teste la désactivation de wp-cron et met en place le cron OVH en remplacement.
Je vais regarder cette histoire de Mailchimp for Woocommerce. kyodev m'avait déjà alerté, mais j'avais complètement oublié de me pencher dessus.

Je vous tiens informés ! Bonne soirée

(PS : @kyodev, le problème de wp-config.php qui s'affiche, c'est parce que je suis un gros sagouin qui a fait une grosse bourde à cause d'un mauvais copier-coller du code de désactivation wp-cron… je viens de la réparer)

je ne suis pas certain..?
en tout cas j'ai aperçu des paramètres de connexion
et là je vois un setup en échec

Hello tout le monde.
Merci pour ce diagnostique. Depuis que j'ai désactivé les tâches planifiées dans Wordpress, je n'ai pas eu une seule fois le problème de timeout.
Cependant j'aimerais être certain que la tâche que j'ai planifiée dans mon interface OVH à la place (et qui appelle le fichier wp-cron.php) fonctionne bien. J'ai tenté de consulter mes logs, mais les seuls archives auxquelles j'ai accès sont celles nommées "web". Tout le reste est du texte simple, sans lien, y compris donc "cron".
Comment puis-je faire ?

```text
05/05/2019 03:35:16 +0200 0 mn 4,362 s
05/05/2019 03:42:05 +0200 1 mn 51,822 s
05/05/2019 03:47:43 +0200 2 mn 30,128 s
05/05/2019 03:52:44 +0200 2 mn 30,129 s
05/05/2019 03:56:15 +0200 1 mn 2,007 s
05/05/2019 04:02:43 +0200 2 mn 30,154 s
05/05/2019 04:07:39 +0200 2 mn 30,124 s
05/05/2019 04:12:44 +0200 2 mn 30,112 s
05/05/2019 04:17:43 +0200 2 mn 30,124 s
05/05/2019 04:22:43 +0200 2 mn 30,127 s
05/05/2019 04:27:43 +0200 2 mn 30,125 s
05/05/2019 04:31:00 +0200 0 mn 50,741 s
05/05/2019 04:35:20 +0200 0 mn 5,821 s
05/05/2019 04:40:18 +0200 0 mn 4,678 s
05/05/2019 04:45:13 +0200 0 mn 4,264 s
05/05/2019 04:50:18 +0200 0 mn 4,375 s
```

pour le cron, tu peux recevoir les logs par emails (en cas d'erreur)
pas de mail, pas d'erreurs

ton site a l'air mieux, mais si cron est le souci...
tu as beaucoup de plugins ayant créé des tâches cron?
pas beaucoup de visites?

Bonjour,

vos suggestions ont amélioré la situation pendant une petite semaine, mais j'ai depuis hier 17h une nouvelle erreur 504 qui s'éternise.
Je pensais que c'était un de mes plugins qui posait problème. J'ai donc désactivé l'ensemble de mon dossier "plugins" via FTP en les renommant avec un suffixe, ainsi que le dossier de cache et le dossier "wp-rocket-config", mais mon site reste désespérément injoignable.

Mes logs, depuis le début de la panne, sont remplis de ce type de lignes :

51.254.41.193 www.1dlx.comdlx.com - [09/May/2019:11:44:54 +0200] "GET /wp-admin/ HTTP/1.1" 499 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36" "runtime: proxy" "server: www.1dlx.comdlx.com"

@PierreFr auriez-vous la possibilité de me dire s'il y a un problème sur le service qui soit extérieur à mon installation de Wordpress ? Ou le problème vient-il bien de mon site et nécessite-t-il mon intervention ?