Site down pendant plusieurs heures de manière aléatoire

Bonjour,

A votre place je commencerais par analyser les logs d'accès web, pour savoir si votre site n'était pas matraqué à ce moment, par exemple par un moteur de recherche.

Et que disait cette erreur 500, svp ?

Bonjour @fritz2cat 🇧🇪 🇪🇺  , 
Merci pour votre réponse. 
J'ai pu consulter les logs et, étant peu compétent dans ce domaine, je les ai uploadés dans Euria (l'IA de Infomaniak) qui me répond notamment ceci : 

>>>>>>>>>>>>

Problème identifié :

Le serveur OVH tue les processus PHP après 160 secondes d’inactivité (idle timeout), ce qui provoque les erreurs 502/500.

🔍 Explication technique :

Les logs montrent des erreurs répétées :

vbnet AH10141: FastCGI: comm with server "/homez.2186/impfgyl/index.php" aborted: idle timeout (160 sec)
AH10149: FastCGI: incomplete headers (0 bytes) received from server

→ Cela signifie que le serveur PHP (via FastCGI) n’a pas répondu dans les 160 secondes → OVH coupe la connexion → le site retourne 502 Bad Gateway ou 500 Internal Server Error.

💡 Pourquoi cela arrive-t-il ?

1. Une tâche CRON ou une requête WordPress prend plus de 160 secondes

→ C’est souvent le cas avec :

• WPML (synchronisation des traductions)
• The Events Calendar Pro (traitement des événements récurrents)
• Matomo (génération de rapports)
• WP-Optimize (nettoyage de la base de données)
• UpdraftPlus (sauvegarde)

→ Ces tâches peuvent prendre des heures si la base de données est grande ou si elles sont mal configurées.

2. Le serveur OVH ne tue pas les processus longs — il les laisse tourner jusqu’à 160 secondes, puis les coupe

→ Cela crée un effet de “plantage” pendant 5h → car la tâche CRON est lancée toutes les 5-15 minutes, et chaque exécution plante après 160 secondes → le serveur est saturé.

 <<<<<<<<<<<<<<<

Donc je comprends que le souci vient du CMS et des plugins installés et dans ce cas, cela doit être WPML.
Mais ce qui me questionne vraiment, c'est que WPML est installé sur de très nombreux autres sites que je gère et je n'ai jamais ce souci. Or ces sites ne sont pas chez OVH.
Cela voudrait-il dire que OVH a plus de limite ?
Merci pour vos lumières, 
Jérôme

Bonjour, 
Merci beaucoup pour votre réponse. 
J'ai consulté les logs et je les ai uploadés dans Euria (IA de Infomaniak) qui me confirme que le souci provient d'un événement Cron (probablement WPML) et que le serveur OVH tue les processus PHP après 160 secondes d’inactivité (idle timeout), ce qui provoque les erreurs 502/500.

Les logs montrent des erreurs répétées :

vbnetCopierAH10141: FastCGI: comm with server "/homez.2186/impfgyl/index.php" aborted: idle timeout (160 sec)
AH10149: FastCGI: incomplete headers (0 bytes) received from server

→ Cela signifie que le serveur PHP (via FastCGI) n’a pas répondu dans les 160 secondes → OVH coupe la connexion → le site retourne 502 Bad Gateway ou 500 Internal Server Error.

Donc je comprends bien que le souci vient de mon installation et d'un plugin mal configurés. 
Mais ce qui me questionne, c'est que j'utilise la même config sur de nombreux autres sites (mais pas chez OVH) et que je n'ai pas ce souci. 
Est-ce qu'il est possible que la configuration OVH ne supporte pas les tâches cron trop longues ? 

Merci pour vos lumières, 

Jérôme

J'espère que la modération ne fait pas le pont viaduc jusqu'au 5 janvier...

Toujours est-il que les réponses de divers intervenants dans plusieurs conversations s'empilent depuis vendredi dernier et produisent cet infâme message d'erreur:

Votre réponse: https://community.ovhcloud.com/community?id=community_question&sys_id=cf7b9a5e0806bed44a4e665cf8d3f9d0&anchor=answer_13d9d6a6b5863a18476b7dec12a8f4ad est donc invisible. Désolé.

Et de nouveau.

https://community.ovhcloud.com/community?id=community_question&sys_id=cf7b9a5e0806bed44a4e665cf8d3f9d0&anchor=answer_3e7e1222b50a3a18476b7dec12a8f484

et

https://community.ovhcloud.com/community?id=community_question&sys_id=cf7b9a5e0806bed44a4e665cf8d3f9d0&anchor=answer_8733eaa2b54a3a18476b7dec12a8f47d

Ca ne sert malheureusement à rien d'insister. C'est la règle ici...

Bonjour @fritz2cat 🇧🇪 🇪🇺  , 
Les réponses ont été modérées et publiées. 
Est-ce que celles-ci peuvent aider ?
Le site a encore été down pendant 45 minutes ce 31/12. 
Merci ! 
Jérôme

En fait c'est très compliqué de donner un diagnostic.

Si jamais c'est l'infrastructure - on parle de "filer" pour les disques - qui sont des unités de stockage - si jamais ces filers sont dans le gaz avec un temps de réponse catastrophique - le chronomètre peut aussi tuer les process même si votre site n'est pas en faute.

Si vous êtes avec une vieille version de PHP (avant 7.4 ?) OVH vous laissait ce choix dans votre configuration PHP:

Qu'en est-il chez vous ? Pouvez-vous le changer ?

Bonjour, 
Je suis sur PHP 8.2. Je pourrais le changer vers 7.4 mais ce n'est pas idéal pour les performances et la sécurité n'est-ce pas ?

En fait, mon raisonnement est assez simple mais peut-être erroné : j'ai beaucoup d'autres sites avec la même configuration chez Infomaniak et je n'ai jamais ce problème. Le site ici en question est relativement simple, je ne vois pas pourquoi des événements cron peuvent prendre tant de temps et bloquer les ressources. Dès lors, j'ai tendance à penser que cela doit provenir de chez OVH mais je suis peut-être dans le faux ;-) 

Petite précision, j'ai installé WP Control me permettant de prendre la main sur tous les événements cron, j'ai pu les lancer manuellement pour voir si le site tenait et il n'y a pas eu de souci. 

Je vais faire une copie du site sur mon hébergement personnel Infomaniak et monitorer tout cela... 

Merci pour votre aide, 

Jérôme

Restez bien en 8.x

Je pense que vous avezraison de ne pas prendre de conclusion trop hâtive concernant votre site. Si vous avez d'autres sites qui se trouvent dans le même hébergement OVH et qui ont aussi des problèmes, ça commence à orienter les recherches vers OVH...

Non, je n'en ai plus. J'en avais beaucoup chez OVH il y a des années mais à force d'être déçu par le support, les performances et les procédures, j'ai déménagé vers Infomaniak ;-) 
Merci pour votre suivi rapide en tout cas, 

Un colistier (lien) a une réponse très pertinente pour vous. Il vous l'exprimera volontiers si "on" (c-à-d OVH) lui en laisse possibilité de poster.

Bonjour @Fabruka ,

Me revoici après vous avoir fait un peu patienter.

En fait j'ai reçu en privé une réponse pertinente d'un colistier : @janus57 que les admins ont banni il y a plus d'un mois (et on ne sait pas pourquoi)

Voici sa réponse. Je vous la livre telle quelle.

________________

Il faut qu'il regarde les logs apache & logs de sortie (OUT) ainsi que les graphiques de l’espace client OVH, car il a peut-être un plugin qui fait de grosses actions la nuit sur des sources externes qui "bride" les connexions (parce que provenant de OVH ou juste parce que le service sature).

Et si un processus PHP reste bloqué dans une action, au bout d'un moment, son hébergement va tomber à zéro processus PHP de dispo et plus aucune page PHP ne va répondre, et ça, c'est "facile" a vérifier il suffit de monitorer une page PHP & une page HTML, si la page PHP est HS mais la page HTML est OK alors c'est qu'il est arrivé au bout des ressources de son hébergement.

Le problème de OVH et qu'il y a absolument 0 documentation ou ces limitations techniques sont écrites, donc impossible d'avoir le nombre de worker PHP en fonction de l'offre (ce qui est con).

Infomaniak communique un peu plus sur ce point : https://www.infomaniak.com/fr/support/faq/2158/modifier-les-limites-phpapache-de-sites-web-depuis-le-manager-infomaniak

Donc, chez infomaniak, la limite en mutu c'est 20 (max_children), ce qui chez OVH correspond aux worker PHP et le seul moyen de savoir si on dépasse cette valeur inconnue chez OVH c'est de regarder le graphique "Dépassements du plafond de ressources", car au niveau code l'ID de cette étiquette est "SYS_WORKER_SPAWN_OVERLOAD".

Sous WordPress il y a ce plugin qui permet d'analyser en profondeur le comportement du site : https://fr.wordpress.org/plugins/query-monitor/

Après, pour les problèmes d'appel de ressources externe : https://wordpress.org/plugins/log-http-requests/ OU https://wordpress.org/plugins/http-requests-manager/ (qui semble sur le papier mieux que "Log HTTP Requests").

Bonjour @fritz2cat 🇧🇪 🇪🇺  et @janus57 ,
Merci pour votre aide ! 

Le graphique de dépassement des ressources est plat comme mon pays et vraisemblablement comme celui de @fritz2cat 🇧🇪 🇪🇺   ;-) 



J'ai installé Query Monitor mais mes compétences sont trop limitées pour interpréter les chiffres. 
Il m'a néanmoins permis de voir 3 messages en rouge à propos d'un plugin permettant de faire le lien entre Elementor et Brevo. Si j'ai bien compris, il faisait des appels très réguliers vers Brevo. Serait-ce une cause ? Je ne sais pas mais j'ai supprimé ce plugin et suis passé par l'intégration direct du formulaire de newsletter Brevo. A voir... 

Le site n'a pas connu de down depuis le 31/12. 

J'ai aussi fait une copie du site sur mon hébergement Infomaniak et à ce stade les performances indiquées dans Pagespeed sont exactement les mêmes. 

Les deux sites sont inscrits sur Uptime Monitor, ainsi, je vais pouvoir précisément observer les moments down. 
Je ne sais pas si mon raisonnement est juste mais si le site connait à nouveau une erreur 500 sur OVH et rien du côté de chez Infomaniak, cela me donne une raison de quitter OVH.

Merci pour votre précieux suivi,

Jérôme

Re-Bonjour, 

Et bien voilà, cela n'a pas duré longtemps, le site est à nouveau down depuis 1h. 
En ajoutant define('DISABLE_WP_CRON', true); dans mon fichier wp-config.php le site est revenu et je peux y naviguer mais impossible d'accéder à l'admin WP, cela tourne...

Et la copie chez Infomaniak tourne sans souci. 

Site à nouveau down pendant 40 minutes et aucun incident sur ma copie Infomaniak.
Je ne comprends pas pourquoi il y a une telle instabilité chez OVH...

Je viens de tout migrer chez Infomaniak, 
Ce fil peut donc être clôturé, 
Merci pour votre aide.