Rien de plus énervant que de ne pas comprendre pourquoi un site fonctionne mal.
Ce soir de nombreux refus d'accès à la base de données privée liée à http://doctsf.com
Une requête est-elle trop longue ? Je regarde donc :
Un outil : le log slow-query archivé sur le serveur Mysql et qu'on peut charger par FTP.
Si le log n'indique rien, ou trois malheureuses requêtes qui mettent 0,015 s quand on les exécuter par PhpMyAdmin, elles ne sont manifestement pas en cause.
Un autre outil, dans l'espace client, hébergements, SQL privé, l'onglet métriques.
Si le graphe ressemble à un ECG de quelqu'un dans le coma (160 Mo utilisés maxi sur 512 alloués), on n'a manifestement pas saturé la RAM du serveur SQL
Toujours dans l'espace client, dans l'hébergement du domaine, onglet Activités de l’hébergement.
Dans dépassement du plafond de ressource, rien depuis 5 jours. Donc encore fausse piste !
Donc dans l'état actuel des investigations :
Mon serveur SQL a des ratés, mes utilisateurs sont furieux.
le log slow-query ne m'apprend rien
les ressources PHP et SQL sont d'après les indicateurs loin d'avoir été dépassées.
Alors que puis-je faire ?..
La dernière fois qu'on m'a dépanné, gentiment d'ailleurs, mon correspondant a isolé dans les logs Web une visite d'un robot Google.
Mais s'il met en bas le serveur par ses scans , quel indicateur me le dira ?
Si un serveur refuse de me répondre parce qu'il est asphyxié, où en trouver la trace et donc la cause ?
J'ai grandement besoin de votre aide.
Cordialement
PS : je sais par ailleurs qu'il faut optimiser les requête SQL et prêter attention aux indexes. C'est ce que je fais mais avec quelques interrogations. Ce sera éventuellement l'objet d'un autre message…
Dans mon espace utilisateur, le graphe de "métriques" ressemble à un encéphalogramme plat. Donc on est loin de la saturation des ressources…
Alors je donne ma langue au chat…
Une des rares requêtes récalcitrantes dans le log slow-query :
# Query_time: 1.054742 Lock_time: 0.001613 Rows_sent: 0 Rows_examined: 0
SET timestamp=1483946486;
INSERT INTO gl_visiteurs (IP, start, user_id)
VALUES ('91.140.89.137',1483946485,0)
ON DUPLICATE KEY UPDATE start=1483946485;
Or, exécutée par phpMyAdmin, elle ne met qu'une fraction de seconde à s'exécuter :
Si duplicate key : 0 ligne insérée. (Traitement en 0.0007 secondes.)
Si insertion : 1 ligne insérée. (Traitement en 0.0127 secondes.)
Cette requête n'est pas en cause, n'est-ce pas ?
Elle est ralentie par une autre, n'est-ce pas ?
Donc il faut que j'inspecte les requêtes qui précèdent ?
Sinon je ne comprends pas…
Hello,
Le pb est-il toujours d'actualité ? on vient de regarder, tout semble normal de notre coté.
Pour rappel le maximums de connexions actives est :
- de 200 connexions actives au total
- de 50 connexions par users,
Ceci étant, dans l'espace client on ne remonte qu'une partie de tes métriques SQLprivé
Une premiere piste si ton souci est toujours d'actu, c'est de récupérer tous les métriques et les analyser
https://docs.ovh.com/fr/fr/web/hosting/recuperer-les-metriques-dun-sql-prive-sur-grafana/
Dans ce document, on explique comment installe Grafana sur un serveur OVH mais tu peux très bien le faire sur ton propre PC ou autre 
le "active connection" sera visible ici
Bonjour et grand merci de te préoccuper de ce problème.
Il n'y a plus rien dans slow-query.log
C'est déjà un bon souci en moins !
Mais je me bats encore contre des 504 gateway time-out
Je suis en train de passer en revue la moindre requête…
Bonjour Jean-MichelB,
Je cherche mais n'arrive pas à trouver où est situé le slow-query.log. Cela m'intéresserait fortement d'y avoir accès. Sauriez-vous me dire ?
Bonsoir
Il est à la racine du serveur Mysql (c'est une base privée)
Accès par FTP, par exemple avec Filezilla