Erreur 504 Gateway Time-out

Bonjour,

A partir de Lundi :

Faire un ticket Incident :

Manager OVH > https://www.ovh.com/manager/#/dedicated/useraccount/dashboard  >  Mes demandes d'assistance  >  Créer une demande / ticket 

puis :

Appeler le SAV OVH au  +33 9 72 10 10 07.
Plutôt  entre 8h et 9h le matin, ou vers 15h il y a moins d'attente.

Où déjà maintenant sur Twitter  @ovh_support_fr  ou   #OVHcloudsupport

Merci.
Comme je le disais dans mon premier message il y a déjà un ticket (introduit vendredi, puis réintroduit samedi avec une capture d'écran du graphique des temps de réponse...).

Toujours aucune réaction ou réponse. Je sais qu'on est le WE, mais que les différents sites soient indisponible plusieurs jours me semble vraiment pénalisant même simplement au niveau des moteurs de recherche...

Bonjour,

Quel Domaine ?

Bonjour,
Ce filerz se porte bien et est loin d'être rempli.
Est-ce que vous pouvez donner le numéro de ticket svp ?
Une erreur 504 ça peut être lié à d'autres choses.
Victor

Voici en pièce jointe les temps de réponse de l'hébergement de https://www.gaudry.be qui montrent manifestement les pics pendant cette période...

Oui il y a des pics de temps de réponse, mais ce n'est pas lié au stockage.

Côté infra je vois que php prend beaucoup de CPU.
Vous avez dû recevoir un email automatique à ce sujet d'ailleurs.

Donc peut-être tenter un boost pour voir si ça va mieux et si c'est le cas voir pour optimiser le code ou monter d'offre performance.

Le seul mail reçu d'OVH me dit ceci:

Merci d'optimiser vos requêtes, d'ajouter des index ou de séparer vos bases de données en plusieurs CloudDB.

Alors je dois avouer que je suis assez mécontent.

J'avais un ancien 60GP avec 1DB d'une taille max de 2Go et 3DB d'une taille max de 1000Go chacune.
On m'a fait la remarque qu'un des sites devenait trop conséquent et je suis passé en février vers l'offre Performance.

Résultat:

• dans mes anciennes DB, la taille est à présent de max 1Go chacune (pour toutes les 4).
  Je sais que dans la nouvelle offre j'ai aussi une DB Cloud de max 8Go, mais je perds la possibilité de travailler avec une DB de repli si j'ai plus de 1Go dessus puisqu'il ne sera donc plus possible de répliquer les données entre les deux DB.
• dans la console google, on voit nettement que depuis quelques mois j'ai perdu 12 millions de pages sur un de mes sites au niveau de l'indexation
• la plus grande part, j'ai ce message Erreur serveur (5xx)
  J'ai tenté de mettre en place un système de bascule automatique entre les deux DB en cas de problème, mais quand il bascule automatiquement sur la DB de repli, j'ai soit le message qui indique trop de connexions (dans les logs je constate maximum 6 connexions ouvertes en même temps dans les gros pics, sinon généralement une connexion), soit carré ment aucun affichage et ce beau message:
  

  504 Gateway Time-out

  ---

  openresty
• La DB cloud consomme trop de mémoire selon ce que je vois sur le monitoring. J'ai fait le test de désactiver, au niveau du DAO du site, la DB cloud. J'ai laissé comme ça pendant deux jours => Sur le monitoring, la mémoire allouée ne descendait pas, et il affichait toujours une connexion. J'ai donc rebranché le connecteur vers cette DB puisque le couper ne fait pas descendre l'utilisation de la RAM.
  Est-ce que c'est le monitoring sur le OVH manager qui affiche des informations erronées, ou est-ce que je m'y prends mal? Comment diminuer la consommation en RAM? Est-ce que je dois redémarrer la Web Cloud Database?

Il y a un système de mise en cache qui évite de devoir faire appel à la DB lors de l'affichage des pages, mais une modification par exemple d'un personnage a non seulement un impact sur la fiche du personnage, mais aussi sur la série dont il provient, sur les lignes du temps dans lesquelles il intervient, sur les pages de géographie des lieux dont il est originaire ou auxquels il est lié... J'ai mis en place ce WE une suppression plus ciblée des pages en cache lors d'une modification, mais ce n'est pas encore assez que pour empêcher que le site soit indisponible lorsqu'il est trop sollicité.

J'avoue que je ne vois plus trop quoi faire...

Si je constate que malgré le passage vers une offre supérieure comme le Performance je ne sais toujours pas héberger le site, je me vois mal passer encore vers une offre plus chère alors qu'il s'agit d'un site qui n'est pas commercial et qui est juste le partage de passions...

Bonjour,

Est il possible d'avoir d'avantages d'informations :

- Taille db/table

- Structures des tables

- Table correctement indexé ? quel moteur ?

- Avez vous une page sans connection DB ? si oui quelles en sont les performances ?

- Requetes frequement utilisée (faire copier/coller de 4 ou requêtes sur les pages a problèmes)

- Version PHP ?

Avez ciblé les pages qui cause le probleme ?

Dèja on va débroussailler un petit peu avec ca...

@CHORINP merci pour ta réponse.

Un simple fichier avec ceci comme contenu:

Quand je veux y accéder, j'ai une erreur 504 après 3.2 minutes.

Donc on peut nettement éliminer les soucis DB :-) D'autant plus que toutes les opérations que j'effectue via phpmyadmin se font rapidement et correctement.

Version php: 8.2
Pages en cause: toutes :(

A présent le test d'affichage d'un simple fichier texte est correct, mais tout ce qui est php ne passe pas, et ce n'est pas limité à un domaine... Les erreurs 504 se présentent sur tous les domaines qui sont stockés sur cet hébergement.

Update: le site semble enfin revenu, sans explications, et sans manipulation de ma part... J'attends un retour d'infos sur le ticket introduit.

Merci pour ces précisions. je ne suis apparemment pas le seul dans le cas, je viens de lire un message similaire sur le forum. 

Je vais investiguer pour voir si il est possible de couper ces processus lorsque ça se produit.

Tout fonctionnait à merveille pendant des jours, et puis à nouveau... Erreur 504... Sur tous les sites de différents domaines hébergés au même endroit. Et c'est encore une fois le moteur php qui ne répond plus :(

Bonjour,

Je confirme que la redirection de http vers https est instantanée. Il n'y a donc pas eu de problème pour lire le .htaccess.

Et ensuite ça mouline pendant de longues minutes (exactement 190 secondes) avant de lancer un 504.

Avez-vous été voir l'error log dans votre espace client > hebergement > logs ? Normalement il devrait y avoir de l'info utile dedans.

@fritz2cat 🇧🇪 🇪🇺  merci pour ta réponse.

Voilà ce que je peux y voir pour les dernières entrées:

Je n'ai pas plus d'infos...

Sur les logs d'erreurs, voici un exemple de ce qui s'affiche

@janus57 

Le problème est réapparu aujourd'hui de 09h00 à 15h00 => toutes les pages étaient en Erreur 504.

Pour les graphes:

• Requêtes HTTP:
  • 2xx: on passe à zéro quand le problème à commencé (vers 9h00) et ça remonte au niveau des hits dès que le problème a pris fin (vers 15h);
  • 3xx: aucune modification; ça reste proche de zéro;
  • 4xx: aucune modification; de temps en temps ça monte vers 7 ou 8 hits/min;
  • 5xx: étrange, la ligne reste à zéro même pendant l'incident, alors que pourtant c'était systématiquement une erreur 504;
    
    
• Temps moyen de réponse: un pic énorme dans l'heure qui précède l'incident, puis ça passe à zéro pendant toute la durée de l'incident, puis ça remonte sans être catastrophique après l'incident (et ça se stabilise);
  
  
• Connexions sortantes: idem requêtes HTTP 2xx;
  
  
• Utilisation du CPU: un pic dans l'heure avant le crash, puis une sinusoïde très faible pendant tout l'incident, puis une légère remontée stabilisée après l'incident;
  
  
• Dépassement du plafond de ressources: zéro avant l'incident; monte en flèche +-30 min après que les pages commencent à être toutes en Erreur 504, puis le pic redescend après une heure, mais reste par vagues assez hautes; puis redescend à zéro après l'incident;

• Statistiques des bases de données: des vagues de hits par min au fil des jours, puis proche de zéro pendant tout l'incident; remonte à son niveau de vagues après l'incident.

Dans les logs OUT, des adresses reviennent souvent (probablement des bots, ou les crawlers des moteurs de recherche). Voici un exemple:

[2025 Jul 17 14:17:35] TCP:57148 => 185.15.58.224:443
[2025 Jul 17 14:17:35] TCP:57162 => 185.15.58.224:443
[2025 Jul 17 14:17:36] TCP:57168 => 185.15.58.224:443

Je ne sais pas si avec ces explications c'est un peu plus clair...