Bonjour,
Mon site : https://www.diveexploreindonesia.com/
Est innacessible depuis environ une heure. j'ai les deux erreurs suivantes :
DNS_PROBE_FINISHED_NXDOMAIN
Et si je tappe l'IP http://213.186.33.176/ j'ai le droit à une page m'indiquant :
Error 520: Website not authorized on OVH CDN
J'ai au début penser que c'était au niveau de ma conenction, mais j'ai testé sur mobile, depuis plusieurs FAI, avec sans proxy etc, et divers service web type GTMETRIX, et aucun n'arrive à se connecter au site.
Je n'ai rien modifier dans la configuration des DNS ou quoi que ce soit depuis des mois.
Merci de corriger rapidement le problème ainsi que de m'en indiquer la source.
Cordialement,
Jana.
Bonjour
Il semble que le domaine n'a pas été payé /renouvelé à temps..
http://www.1raynette.fr/whois/diveexploreindonesia.comraynette.fr/whois/diveexploreindonesia.com
Registrar Registration Expiration Date: 2017-02-09T14:14:26Z
On est le 11 février..
La honte…
Merci…
Chez moi, c'est bon :
"DIVE EXPLORE INDONESIA
YOUR INDONESIA FOCUSED DIVING TRAVEL AGENCY"
La paiement du domaine a dû avoir lieu puisque la date d'expiration est maintenant
Registrar Registration Expiration Date: 2018-02-09T14:14:26Z
Merci beaucoup Fritz2cat !
N'hésitez pas si vous êtes intéressé 
Et merci à tout le monde, on a repayé le domaine tout de suite et c'est revenu…
Jusqu'à maintenant mais c'est un autre sujet 
Jana.
Bonjour,
Aujourd'hui c'est un des miens qui est inaccessible. Cela arrive environ 1 fois par mois, c'est agaçant et surtout très couteux.
Si quelqu'un d'OVH passe dans le coin, voici l'URL: https://www.1abs.frabs.fr
J'ai ouvert un ticket. Après quelques heures d'indisponibilité totale le site est de nouveau accessible.
Je tiens donc à remercier les techniciens d'OVH mais je préfèrerais qu'ils me disent :
-"ça y est, nous sommes intervenus, votre site fonctionne"
plutôt que :
-"Bah non, il n'a rien votre site, il fonctionne très bien"
J'ai quand même l'impression d'être pris pour un idiot. 
Bonjour,
et si ils ne sont réellement pas intervenu dessus et que c'est tout simplement les worker PHP qui était saturé (pour une raison X qui risque de se trouver dans le code PHP de votre site) ?
Et parfois c'est ça car la dernière personne qui avait eu ce message de la part de l'assistance OVH avait reàus une réponse ultra détaillé sur le forum ou un admin avait analyser le site du client et constaté que celui-ci saturer tous ces worker PHP = > site HS (ce qui est normal car plus de place pour traiter les requêtes des clients).
Cause de la saturation ?
Bien souvent un script qui va chercher une ressources ailleurs et cette dite ressource qui peu mettre X secondes à répondre voir par répondre (et ça c'est le pire cas qu'il puisse exister).
Cordialement, janus57
Mouais… Ce qui serait intéressant c'est que le technicien d'OVH valide cette hypothèse ET indique où se trouve la ressource que le script va chercher.
Parce que si c'est le problème, celui-ci va forcément se répéter.
Est-ce que ce problème impacte tous les mutualisés du même cluster?
Enfin pour ma part, j'ai un gros doute parce que le message d'OVH signalant que tout va bien arrive toujours quelques minutes après le rétablissement de l'accès au site.
Est-ce que ce problème impacte tous les mutualisés du même cluster?
Si c'est un script/boucle infinie dans un dossier, non çà ne bloque qu'un hébergement (l'hébergement du client).
Si après, il y a un problème de "fichiers" çà bloque certains clients mais pas tout, car chaque cluster à plusieurs "serveurs de stockage de fichiers".
Bonjour,
Mouais… Ce qui serait intéressant c'est que le technicien d'OVH valide cette hypothèse ET indique où se trouve la ressource que le script va chercher.
sauf que c'est pas au support OVH de faire le débug des sites client, c'est au client de débug son site ou au concepteur du site mais certainement pas OVH qui lui fournit simplement les outils nécessaire à la mise en ligne du site.
Est-ce que ce problème impacte tous les mutualisés du même cluster?
non cela touchera juste votre plan d'hébergement car OVH "emprisonne" chaque client pour justement éviter une cascade si un client sature méchamment le serveur (ici il se saturera lui même et tous ces sites à lui et les autres client n'auront strictement rien).
Enfin pour ma part, j'ai un gros doute parce que le message d'OVH signalant que tout va bien arrive toujours quelques minutes après le rétablissement de l'accès au site.
c'est soit une coïncidence soit le support qui a restart les worker et forcément tout re-fonctionne mais le problème d'origine est toujours présent.
Vous pouvez même le faire vous même, à savoir passer en en moteur phpcgi puis re-passer sur le moteur php. Si après cette manipulation le site revient comme par magie vous avez une boucle et/ou un problème d’exécution d'un script et/ou un script qui va chercher quelque chose ailleurs qui bloque tout le reste
Cordialement, janus57
Merci Janus57 pour cette réponse détaillée.
Dans l'hypothèse où un script tente d'aller chercher une ressource "ailleurs"; comment détecter ce script? Je précise qu'il s'agit d'un site sous Wordpress.
Sinon, "passer en moteur phocgi puis re-passer sur le moteur php", j'en comprends le principe mais comment réaliser cela??
Bonjour,
En regardant les logs "out" cela devrait déjà donner une idée de ce que wordpress et plugins associé va chercher à l’extérieur et les fréquence si il y a un horodatage.
Et pour le moteur PHP il suffit dans le .ovhconfig de passer de "app.engine=php" (PHP-FPM) à "app.engine=phpcgi" (PHP FastCGI) pendant 5 minutes puis de faire l'inverse (PHP-FPM est beaucoup plus rapide/puissant pour votre site).
Sinon l'autre méthode est de passer par le manager OVH (mais j'ai pas de screen à proposer pour expliciter).
Cordialement, janus57
Et parfois c'est ça car la dernière personne qui avait eu ce message de la part de l'assistance OVH avait reàus une réponse ultra détaillé sur le forum ou un admin avait analyser le site du client et constaté que celui-ci saturer tous ces worker PHP = > site HS (ce qui est normal car plus de place pour traiter les requêtes des clients).
Je crois que c'était moi l'admin :slight_smile:
Alors, je vais donner ma petite recette secrète car elle ne se base que sur des données accessible depuis l'espace client ou les logs.
Est ce que le site a dépassé les ressources qui lui sont attribuées ? Pour cela, il est possible de regarder le graphe dans l'espace client nommé "Dépassement du plafond de ressources". Pour 1abs.fr,abs.fr, j'aperçois en effet un dépassement de ressources le 24 février entre 16 et 17h30. Quelque chose a mangé toutes mes ressources.
Si c'est un dépassement de ressources :
* Pour le trouver, je regarde le graphes des connexions sortantes : appels vers des API externes comme twitter et facebook, mises à jour de wordpress.... C'est souvent une cause de ralentissement des pages web, et donc d'utilisation des ressources (moins de pages web disponibles par minutes, donc moins de visiteurs). Dans notre cas, il y a bien des connexions sortantes, mais leur nombre n'est pas préocuppants (pas de pic en même temps que le dépassement de ressources).
* Je regarde les temps de réponse et nombre de requêtes SQL. A nouveau, rien de spécifique à signaler sur le 24 février. Ce ne sont pas les requêtes en base de données qui ralentissent le site.
* Je vais voir les logs. Ceux d'erreur sont intéressants. Quand je regarde ceux du 24, je vois plein de lignes avec
`aborted: idle timeout (300 sec)`
ou
`FastCGI: An error happend on Fastcgi processing, fallback to CGI,`
Dans les deux cas, cela signifie que la page indiquée à dépassée les 300 secondes d'exécution et a donc consommé des ressources pendant 300 secondes.
Il y en a plein dans les alentours de 16h/16h30. Le soucis vient donc de là. Un des scripts indiqué mange beaucoup de ressources. Il faut regarder les première lignes puisque celle de la fin correspondent à des pages qui sont ralenties car toutes les ressources sont déjà prises.
Quand je regarde ici, sans donner les pages précises pour que personne ne t'attaque après m'avoir lu, je vois deux pages qui sont fortement impactées par cette erreur.
`[Fri Feb 24 15:58:27 2017] [error] [client 176.xxx.xxx.xxx] [host www.1abs.fr]abs.fr] (103)Software caused connection abort: Failed to flush CGI output to client, referer: https://www.1abs.fr/xxxxxxxxx` abs.fr/xxxxxxxxx`
`[Fri Feb 24 15:48:25 2017] [error] [client 176.xxx.xxx.xxx] [host www.1abs.fr]abs.fr] FastCGI: incomplete headers (0 bytes) received from server "xxxxxx", referer: https://www.1abs.fr/xxxxxxxx` abs.fr/xxxxxxxx`
Je te laisse aller voir directement le log pour connaître les url exactes.
Tout ce que je peux dire, c'est que le plugin 'woocommerce-apple-pay-license' revient souvent. Au vu du nom, je dirais que le système de validation de license mange toutes les ressources de ton hébergement. Bref, ce plugin prend probablement toutes tes ressources à ce moment.
Deux solutions :
1. Changer de plugins
2. Changer d'offre pour avoir un plafond de ressources plus grand.
J'espère que ca t'aura aidé (et que ca aidera d'autres personnes à trouver l'origine de leurs soucis).
Bon debug.
Vincent
casse, merci beaucoup pour ce petit cours très clair et très instructif sur l'usage des fichiers logs.
Effectivement, la validation de licence du plugin en question a posé problème ce jour là. Je reste cependant dubitatif car j'avais effacé le plugin via FTP en pensant justement que le problème venait de là mais l'inaccessibilité du site à perduré plusieurs heures.
Bonjour,
Mon site est à nouveau inaccessible. (504 Gateway Time-out).
J'ai testé la méthode de Janus57 sans succès.
Il n'y a pas de fichiers logs pour le moment et la rubrique "Dépassement du plafond de ressources" n'a aucune donnée à afficher.
Le reste des graphes n'indique à priori rien d'anormal.
Je ne sais plus quoi faire.
Quelqu'un de chez OVH est intervenu. Ouf!
Pour, le site refonctionnait après l'intervention d'OVH mais une étrange erreur s'affichait dans le Back End de wordpress. Je viens de constater que cette erreur venait d'une de mes manipulations destinées à débloquer le site. dans mon .ovhconfig j'avais:
app.engine= php
Au lieu de
app.engine=php
notez l'espace après le "=".
J'ai eu l'explication grâce aux fichier logs 
ça y est, ça recommence : "504 Gateway Time-out"
J'en ai marre.