Bonjour
Je sais, il y a surement une raison.
Le problème est que je m'arrache les derniers cheveux à trouver, sans succès.
L'un d'entre vous sera surement plus malin ?
La requête :
insert into gl_trace
set trace_date= now(),
trace_ip='5.21.252.72',
trace_code='9999',
trace_appelant='index.php',
trace_action='trace',
trace_detail='',
contrib=0,
ref='0',
ref2='0',
admin=0,
debug=0,
public=0,
erreur=1;
Exécutée à la volée dans PhpMyAdmin, elle met 0.01 à 0.02 secondes.
Par php, elle se retrouve dans le log des slow-query, de nombreuses fois, à plus d'une seconde.
La table n'a rien de spécial.
J'ai relancé le moteur mysql, purgé, analysé, et même vidé la table.
J'ai tenté de comparer InnoDB et MyIsam, pas de différence.
Le souci est que de temps en temps mon site rame, et je suis en train d'optimiser au maximum les requêtes. Celle-ci est l'une des deux qui me fait des misères…
Quelqu'un a-t-il un éclair de génie ?
Un grand merci par avance.
Jean-Michel
L'environnement : j suis en PrivateMysql, sur privatesql012, Docker Paris, cluster 006, sous un hébergement perf2014, 512 Mo de RAM…
Bonjour,
Quelle version de php ?
Environnement stable ?
https://docs.ovh.com/fr/fr/web/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/
C'est mieux php 5.6 ou supérieur et environnement stable.
Ton site rame a cause des requêtes uniquement ou d'autres choses ?
C'est un site développé perso ? Ou basé sur un CMS ?
Merci de t'intéresser à la question.
Le site est sous PHP 5.6 stable.
Le site est 100% perso, fonctionne bien depuis des années.
Il ne rame pas spécialement, mais de temps en temps il mouline, et finit par tomber sur une sorte de timeout : une Page OVH avec message "there is a problem…".
La dernière fois que j'ai signalé au support OVH une inaccessibilité accidentelle de mon site, le technicien m'a dit que des tâches dans Mysql étaient en état "sleep".
J'ai donc depuis optimisé mes requêtes et soigneusement ajusté tous les indexes de tables.
C'est pourquoi exaspéré par ces coupures très pénalisantes et dont se plaignent mes utilisateurs, je m'attelle à optimiser mysql, pour au moins exclure cette piste.
Dans les logs deux requêtes dépassent la seconde, dont celle-ci (je traite un problème à la fois).
Cette requête est toute bête et ne fait qu'un insert dans une petite table toute bête.
Peut-être arrive-t-elle simplement au mauvais moment ?
Mais si c'est le cas, pourquoi elle spécialement revient souvent dans mon log et non pas toutes les autres, et elles sont nombreuses parmi toutes mes pages php…
Grand mystère…
Si elle ne le fait pas souvent c'est peut être d'autres requêtes en amont qui chargent le mysql..
Au niveau de mysql quelle est l'utilisation de la mémoire ?
Dans ton code php tu fermes bien les connexions SQL ?
Mysql surchargé : c'était une de mes hypothèses.
C'est pourquoi j'ai monté la RAM à 512 Mo.
Actuellement, dans le monitoring, la courbe de RAM n'a jamais dépassé 150 Mo, pour 512 Mo dispo.
Surtout, j'ai des dizaines de requêtes qui s'exécutent sans apparaitre dans les logs. Celle de cette discussion est l'une des très rares. Alors elle est probablement en cause…
Par contre l'autre problème est un message régulièrement dans le log slow-query : "#126 - Incorrect key file for table '/dev/shm/#sql_1_0.MYI'; try to repair it" sur une requête select gourmande. Je comptais ouvrir un autre sujet.
Fermeture des connexions SQL : oui, dans chaque page php.
Pour réparer tes tables/bases SQL tu peux le faire via une requêtes SQL dans php.
Je le fais périodiquement.
Je pourrais te sortir le code au besoin demain ou mercredi.
J'ai réparé manuellement les tables, ça ne change rien.
D'après mes recherches ce message indique plutôt un dépassement de l'espace alloué aux tables temporaires.
Je ne sais pas ce que tu peux personnaliser ou pas sur les SQL privé..
On peut personnaliser :
autoCommit : Activé
innodbBufferPoolSize : 64 (MB)
maxAllowedPacket : 8
maxConnections : 100
tmpdir : /dev/shm
Ça me donne envie d'essayer en changeant tmpdir. On a une option "/tmp"
> /dev/shm : Le serveur SQL Privé allouera la moitié de sa mémoire RAM à ce répertoire pour plus de performances.
> /tmp : Le serveur allouera sur son disque dur une espace illimité pour ce répertoire, mais cela sera beaucoup moins performant. Nous vous conseillons d’utiliser ce répertoire uniquement pour les opérations occasionnelles lourdes.
Bonjour
Après diverses optimisations, le site ne subit plus de timeout.
Cependant, il reste une énigme :
Dans les slow-query.log, une toute petite requête de rien du tout apparaît plusieurs fois par jour. Ce n'est pas très gênant en soi mais c'est toujours inquiétant de voir quelque-chose que l'on ne comprend pas.
La requête :
> delete from gl_visiteurs where IPVALUE = INET_ATON('88.176.244.56');
On ne peut pas plus simple !
En phpmyadmin, elle met 0.0009 s à s'exécuter.
Or le slow-query.log dit
> Query_time: 1.192519 Lock_time: 0.000145
Explain dit :
> select_type : SIMPLE
> possible_keys : ipvalue
> key : ipvalue
> ref : const
> rows : 1
> Using where
La structure de la table :
> CREATE TABLE IF NOT EXISTS `gl_visiteurs` (
> `IP` varchar(15) CHARACTER SET utf8 NOT NULL DEFAULT '',
> `start` int(11) DEFAULT NULL,
> `logue` int(11) NOT NULL DEFAULT '0',
> `user_id` int(11) NOT NULL,
> `ipvalue` int(11) NOT NULL DEFAULT '0'
> ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
> ALTER TABLE `gl_visiteurs`
> ADD PRIMARY KEY (`IP`,`user_id`),
> ADD KEY `user_id` (`user_id`),
> ADD KEY `start` (`start`),
> ADD KEY `ipvalue` (`ipvalue`);
Enfin, la table ne compte que 64 enregistrements.
Cela intervient n'importe quand, a priori sans lien avec l'activité de mon site.
Et… seule cette requête et son équivalent en insert apparaissent dans le log.
> Query_time: 2.183902 Lock_time: 0.000074 Rows_sent: 0 Rows_examined: 0
> SET timestamp=1484727442;
> INSERT INTO gl_visiteurs (IP, IPVALUE, start, user_id)
> VALUES ('66.249.91.150',INET_ATON('66.249.91.150'), 1484727440, 0);
Alors qu'il y a pas mal de requêtes plus complexes sur le site.
J'ai optimisé tout ce que j'ai pu, d'ailleurs le site ne pose plus de problème.
Mais j'aimerais bien avoir les slow-query.log à 0, ne serait-ce que pour les surveiller plus facilement.
Si l'un d'entre vous avait une idée, ce serait top !..
Merci d'avance
Edit : je remarque que la table est en latin. Je viens de la repasser en UTF_8_general_CI qui est le standard sur mon site. Mais quelques autres tables sont dans ce cas, sans apparaître pour autant dans les logs.