Problème de lenteur excessive pour le vidage de cache

Général
1

Bonjour,

SPIP 3.1
PHP 5.6.24

Je viens de changer d'hébergement pour 130 sites que je gère en spip 3.1, pour les mettre sur un serveur dédié chez OVH, serveur qui est censé dépoter :
CPU : Intel Xeon E3 4c/8t @3.4GHz
RAM : 32Go DDR3 ECC 1600MHz
Disques 2x480Go SSD RAID 1 SOFT
Ces sites ont chacun leur noyau spip et partagent les squelettes, plugins, options.
Tout fonctionne bien après migration sauf une lenteur très excessive lorsque je vide le cache d'un site (jusqu'à 30-40 secondes pour vider un cache de site).
En local, les mêmes sites sous xunbuntu en machine virtuel en php 5.6.30 avec seulement 6Go de RAM dédié et un bon vieux core 2 duo quad ne mettent que 3 ou 4 secondes à faire la même chose. Sur l'ancien hébergement je n'avais pas de souci de long délai non plus, alors qu'il était bien moins puissant et en mutualisé.

Si je regarde spip.log je ne vois rien de particulier, sauf régulièrement des Erreur mysql 2006, ce que je n'avais pas avant.

Je ne sais pas trop comment, par où, explorer le souci, quelqu'un a des pistes à me proposer SVP ? Comment debugger, tracer ?

2

Le 05/02/2017 à 16:19, 6ril a écrit :

Bonjour,

SPIP 3.1
PHP 5.6.24

Je viens de changer d'hébergement pour 130 sites que je gère en spip
3.1, pour les mettre sur un serveur dédié chez OVH, serveur qui est
censé dépoter :
CPU : Intel Xeon E3 4c/8t @3.4GHz
RAM : 32Go DDR3 ECC 1600MHz
Disques 2x480Go SSD RAID 1 SOFT
Ces sites ont chacun leur noyau spip et partagent les squelettes,
plugins, options.
Tout fonctionne bien après migration sauf une lenteur très excessive
lorsque je vide le cache d'un site (jusqu'à 30-40 secondes pour vider un
cache de site).
En local, les mêmes sites sous xunbuntu en machine virtuel en php 5.6.30
avec seulement 6Go de RAM dédié et un bon vieux core 2 duo quad ne
mettent que 3 ou 4 secondes à faire la même chose. Sur l'ancien
hébergement je n'avais pas de souci de long délai non plus, alors qu'il
était bien moins puissant et en mutualisé.

Si je regarde spip.log je ne vois rien de particulier, sauf
régulièrement des Erreur mysql 2006, ce que je n'avais pas avant.

Je ne sais pas trop comment, par où, explorer le souci, quelqu'un a des
pistes à me proposer SVP ? Comment debugger, tracer ?

Si ça peut aider, en mettant le niveau de log en _LOG_DEBUG dans mes_options, j'obtiens une minute d'écart entre ces deux actions:

2017-02-06 12:46:08 ip (pid 30500) :Pri:info: Analyser DTD SYSTEM ../prive/paquet.dtd (3.096 ms) 18 macros, 19 elements, 17 listes d'attributs, 253 entites

2017-02-06 12:47:09 ip (pid 30500) :Pri:debug: GET ./?exec=admin_vider - ../config/connect.php

Personne pour un piste SVP ?

3

Le 06/02/2017 à 12:57, 6ril a écrit :

Le 05/02/2017 à 16:19, 6ril a écrit :

Bonjour,

SPIP 3.1
PHP 5.6.24

Je viens de changer d'hébergement pour 130 sites que je gère en spip
3.1, pour les mettre sur un serveur dédié chez OVH, serveur qui est
censé dépoter :
CPU : Intel Xeon E3 4c/8t @3.4GHz
RAM : 32Go DDR3 ECC 1600MHz
Disques 2x480Go SSD RAID 1 SOFT
Ces sites ont chacun leur noyau spip et partagent les squelettes,
plugins, options.
Tout fonctionne bien après migration sauf une lenteur très excessive
lorsque je vide le cache d'un site (jusqu'à 30-40 secondes pour vider un
cache de site).
En local, les mêmes sites sous xunbuntu en machine virtuel en php 5.6.30
avec seulement 6Go de RAM dédié et un bon vieux core 2 duo quad ne
mettent que 3 ou 4 secondes à faire la même chose. Sur l'ancien
hébergement je n'avais pas de souci de long délai non plus, alors qu'il
était bien moins puissant et en mutualisé.

Si je regarde spip.log je ne vois rien de particulier, sauf
régulièrement des Erreur mysql 2006, ce que je n'avais pas avant.

Je ne sais pas trop comment, par où, explorer le souci, quelqu'un a des
pistes à me proposer SVP ? Comment debugger, tracer ?

Si ça peut aider, en mettant le niveau de log en _LOG_DEBUG dans
mes_options, j'obtiens une minute d'écart entre ces deux actions:

2017-02-06 12:46:08 ip (pid 30500) :Pri:info: Analyser DTD SYSTEM
../prive/paquet.dtd (3.096 ms) 18 macros, 19 elements, 17 listes
d'attributs, 253 entites

2017-02-06 12:47:09 ip (pid 30500) :Pri:debug: GET ./?exec=admin_vider -
../config/connect.php

Personne pour un piste SVP ?

J'ai à chaque fois une minute et 1 seconde entre ces deux actions, comme si un timeout avait lieu au bout d'une minutes qui permettait à la transaction de poursuivre ensuite.

En local je n'ai que 4 secondes entre ces deux actions:

2017-02-06 16:33:50 127.0.0.1 (pid 14514) ecrire/xml/analyser_dtd.php:L58:charger_dtd()::Pri:info: Analyser DTD SYSTEM ../prive/paquet.dtd (13.041 ms) 18 macros, 19 elements, 17 listes d'attributs, 253 entites

2017-02-06 16:33:54 127.0.0.1 (pid 14514) ecrire/inc_version.php:L515:include()::Pri:debug: GET ./?exec=admin_vider - ../config/connect.php

Il y a donc quelque chose sur mon nouveau serveur qui bloque, mais quoi ???

4

Le 06/02/2017 à 12:57, 6ril a écrit :

Le 05/02/2017 à 16:19, 6ril a écrit :

Bonjour,

SPIP 3.1
PHP 5.6.24

Je viens de changer d'hébergement pour 130 sites que je gère en spip
3.1, pour les mettre sur un serveur dédié chez OVH, serveur qui est
censé dépoter :
CPU : Intel Xeon E3 4c/8t @3.4GHz
RAM : 32Go DDR3 ECC 1600MHz
Disques 2x480Go SSD RAID 1 SOFT

Effectivement, cela devrait dépoter.

Si ça peut aider, en mettant le niveau de log en _LOG_DEBUG dans
mes_options, j'obtiens une minute d'écart entre ces deux actions:

2017-02-06 12:46:08 ip (pid 30500) :Pri:info: Analyser DTD SYSTEM
../prive/paquet.dtd (3.096 ms) 18 macros, 19 elements, 17 listes
d'attributs, 253 entites

2017-02-06 12:47:09 ip (pid 30500) :Pri:debug: GET ./?exec=admin_vider -
../config/connect.php

Personne pour un piste SVP ?

Regarder la mémoire allouée à PHP, mettre un script d'analyse de mysql style
https://launchpad.net/mysql-tuning-primer/trunk/1.6-r1/+download/tuning-primer.sh
y en a d'autres.
est ce que le serveur swap?
etc...

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

5

Pas de log MySQL ou erreur log aveur un time out ?

Sinon retourn au mutu :wink:

6

Le 06/02/2017 à 16:39, 6ril a écrit :

Le 06/02/2017 à 12:57, 6ril a écrit :

Le 05/02/2017 à 16:19, 6ril a écrit :

Bonjour,

SPIP 3.1
PHP 5.6.24

Je viens de changer d'hébergement pour 130 sites que je gère en spip
3.1, pour les mettre sur un serveur dédié chez OVH, serveur qui est
censé dépoter :
CPU : Intel Xeon E3 4c/8t @3.4GHz
RAM : 32Go DDR3 ECC 1600MHz
Disques 2x480Go SSD RAID 1 SOFT
Ces sites ont chacun leur noyau spip et partagent les squelettes,
plugins, options.
Tout fonctionne bien après migration sauf une lenteur très excessive

...

2017-02-06 16:33:54 127.0.0.1 (pid 14514)
ecrire/inc_version.php:L515:include()::Pri:debug: GET
./?exec=admin_vider - ../config/connect.php

Il y a donc quelque chose sur mon nouveau serveur qui bloque, mais quoi ???

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

Il y a aussi cela qui est complémentaire pour mysql, il y a aussi le mode rescue sur ovh pour voir si il n'y a pas de pb matériel?

7

Le 06/02/2017 à 18:09, DjackO a écrit :

Il y a aussi cela qui est complémentaire pour mysql, il y a aussi le
mode rescue sur ovh pour voir si il n'y a pas de pb matériel?

j'avais oublié le lien

8

Le 06/02/2017 à 18:41, DjackO a écrit :

Le 06/02/2017 à 18:09, DjackO a écrit :

Il y a aussi cela qui est complémentaire pour mysql, il y a aussi le
mode rescue sur ovh pour voir si il n'y a pas de pb matériel?

j'avais oublié le lien

GitHub - major/MySQLTuner-perl: MySQLTuner is a script written in Perl that will assist you with your MySQL configuration and make recommendations for increased performance and stability.

Bonsoir DjackO et Pierre,
Merci pour vos réponses, au niveau des logs mysql que j'ai tous consultés (/var/log/mysql/) je ne vois vraiment rien qui se rapporte au vidage de cache.
J'avais dans le log spip une erreur 2006 que j'ai réglé en rallongeant le délai wait_timeout de 60 à 300 (my.cnf) mais ça ne change rien au souci relaté dans ce fil.
J'ai bien songé à un souci hardware (deux ssd en raid mirroring soft). J'ai un accès root au serveur mais l'infogérance en est confiée à une boite dont l'hébergement sur serveur dédié ovh est la spécialité, donc le mode rescue je ne connais pas (pas encore), et mon correspondant m'affirme que l'on n'a pas de souci avec les disques.
Je ne connais rien au monitoring mysql, mais si je me réfère aux logs et l'absence de trace, ça ne semblerait pas provenir de là (?)

Par ailleurs, une autre latence énorme (30/45 scs) rencontrée est si on vide local et tmp et qu'on retourne à l'accueil (reconstitution des fichiers).

Les droits sont en 700 (pas en 777), ce qui ne semblent pas poser souci. Je les ai passé temporairement à 777 au cas où, mais en vain pour ce qui concerne le pb.

9

Bonjour,

pas de problèmes physiques ? ( SMART, contrôleur raid s'il y en a un, température CPU excessive ).

Et sinon, il y a combien de fichiers dans le cache en question car bon, ça peut être long. Et enfin, quel type de formatage sur le système de fichiers ?

10

Le 06/02/2017 à 21:08, Vincent a écrit :

Bonjour,

pas de problèmes physiques ? ( SMART, contrôleur raid s'il y en a un,
température CPU excessive ).

Et sinon, il y a combien de fichiers dans le cache en question car bon,
ça peut être long. Et enfin, quel type de formatage sur le système de
fichiers ?

Pour les problèmes physiques j'en sais rien, je n'ai pas une grande habitude de Linux. Il y a une commande particulière qu eje pourrais testée ? Pour la taille du cache, et son nombre de fichiers:
J'ai l'identique en local sur une machine virtuelle comme indiqué en entête et je n'ai que 3 secondes de latences sur cette VM.
De plus si je vide le cache (sur le serveur dédié) plusieurs fois de suite, j'ai toujours le souci à chaque fois (donc même avec un cache vide).
Pour le système de fichier voila ce que me dit parted:

# parted /dev/sda print all
Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
  1 2097kB 21,0GB 21,0GB primary ext4 boot, raid
  2 21,0GB 480GB 459GB primary ext4 raid
  3 480GB 480GB 536MB primary linux-swap(v1)

Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sdb: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
  1 2097kB 21,0GB 21,0GB primary ext4 boot, raid
  2 21,0GB 480GB 459GB primary ext4 raid
  3 480GB 480GB 536MB primary linux-swap(v1)

Model: Linux Software RAID Array (md)
Disk /dev/md1: 21,0GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
  1 0,00B 21,0GB 21,0GB ext4

Model: Linux Software RAID Array (md)
Disk /dev/md2: 459GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
  1 0,00B 459GB 459GB ext4

----------------

11

Le 06/02/2017 à 21:27, 6ril a écrit :

Le 06/02/2017 à 21:08, Vincent a écrit :

Bonjour,

pas de problèmes physiques ? ( SMART, contrôleur raid s'il y en a un,
température CPU excessive ).

Et sinon, il y a combien de fichiers dans le cache en question car bon,
ça peut être long. Et enfin, quel type de formatage sur le système de
fichiers ?

Pour les problèmes physiques j'en sais rien, je n'ai pas une grande
habitude de Linux. Il y a une commande particulière qu eje pourrais
testée ? Pour la taille du cache, et son nombre de fichiers:
J'ai l'identique en local sur une machine virtuelle comme indiqué en
entête et je n'ai que 3 secondes de latences sur cette VM.
De plus si je vide le cache (sur le serveur dédié) plusieurs fois de
suite, j'ai toujours le souci à chaque fois (donc même avec un cache vide).
Pour le système de fichier voila ce que me dit parted:

# parted /dev/sda print all
Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 2097kB 21,0GB 21,0GB primary ext4 boot, raid
2 21,0GB 480GB 459GB primary ext4 raid
3 480GB 480GB 536MB primary linux-swap(v1)

Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sdb: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 2097kB 21,0GB 21,0GB primary ext4 boot, raid
2 21,0GB 480GB 459GB primary ext4 raid
3 480GB 480GB 536MB primary linux-swap(v1)

Model: Linux Software RAID Array (md)
Disk /dev/md1: 21,0GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0,00B 21,0GB 21,0GB ext4

Model: Linux Software RAID Array (md)
Disk /dev/md2: 459GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0,00B 459GB 459GB ext4

----------------

Et je viens de passer smartmontools sur les deux disques, aucune erreur.

12

fais une commande top et regarde la ligne concernant average, le premier chiffre ne doit pas être supérieur à 1et regarde si il ya des processus qui tournent en boucle sur le serveur.
Abdel

Envoyé depuis Yahoo Mail pour Android

Le 06/02/2017 à 21:27, 6ril a écrit :

Le 06/02/2017 à 21:08, Vincent a écrit :

Bonjour,

pas de problèmes physiques ? ( SMART, contrôleur raid s’il y en a un,
température CPU excessive ).

Et sinon, il y a combien de fichiers dans le cache en question car bon,
ça peut être long. Et enfin, quel type de formatage sur le système de
fichiers ?

Pour les problèmes physiques j’en sais rien, je n’ai pas une grande
habitude de Linux. Il y a une commande particulière qu eje pourrais
testée ? Pour la taille du cache, et son nombre de fichiers:
J’ai l’identique en local sur une machine virtuelle comme indiqué en
entête et je n’ai que 3 secondes de latences sur cette VM.
De plus si je vide le cache (sur le serveur dédié) plusieurs fois de
suite, j’ai toujours le souci à chaque fois (donc même avec un cache vide).
Pour le système de fichier voila ce que me dit parted:

parted /dev/sda print all

Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 2097kB 21,0GB 21,0GB primary ext4 boot, raid
2 21,0GB 480GB 459GB primary ext4 raid
3 480GB 480GB 536MB primary linux-swap(v1)

Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sdb: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 2097kB 21,0GB 21,0GB primary ext4 boot, raid
2 21,0GB 480GB 459GB primary ext4 raid
3 480GB 480GB 536MB primary linux-swap(v1)

Model: Linux Software RAID Array (md)
Disk /dev/md1: 21,0GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0,00B 21,0GB 21,0GB ext4

Model: Linux Software RAID Array (md)
Disk /dev/md2: 459GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0,00B 459GB 459GB ext4

Et je viens de passer smartmontools sur les deux disques, aucune erreur.

liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l’aide à toute heure : http://spip.net/irc

13

Le 06/02/2017 à 21:27, 6ril a écrit :

Le 06/02/2017 à 21:08, Vincent a écrit :

Number Start End Size Type File system Flags
1 2097kB 21,0GB 21,0GB primary ext4 boot, raid
2 21,0GB 480GB 459GB primary ext4 raid
3 480GB 480GB 536MB primary linux-swap(v1)

Model: ATA INTEL SSDSC2BB48 (scsi)
Disk /dev/sdb: 480GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 2097kB 21,0GB 21,0GB primary ext4 boot, raid
2 21,0GB 480GB 459GB primary ext4 raid
3 480GB 480GB 536MB primary linux-swap(v1)

Model: Linux Software RAID Array (md)
Disk /dev/md1: 21,0GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0,00B 21,0GB 21,0GB ext4

Model: Linux Software RAID Array (md)
Disk /dev/md2: 459GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0,00B 459GB 459GB ext4

----------------

que donne cette commande? swapon -s et celle là : top (4 1eres lignes)

536MB de swap, c'est pas assez.

14

Le 06/02/2017 à 21:03, 6ril a écrit :

l'infogérance en est confiée à une boite dont l'hébergement sur serveur
dédié ovh est la spécialité, donc le mode rescue

Ah ok, mode rescue > on oublie. Par contre la "boite dont l'hébergement sur serveur dédié ovh est la spécialité", c'est à elle de trouver le problème, car franchement avec un tel serveur , cela doit tenir le coup à moins que vous ayez 10000 visiteurs simultanés!

et Error Code: 2006 - MySQL server has gone away -> il y a un problème de config mysql. Il faut lancer les scripts que je vous ai indiqué. Maintenant, si vous ne savez pas lire les résultats, il faut voir avec la boite d'infogérance...

15

Le 06/02/2017 à 21:03, 6ril a écrit :

l'infogérance en est confiée à une boite dont l'hébergement sur serveur
dédié ovh est la spécialité, donc le mode rescue

Ah ok, mode rescue > on oublie. Par contre la "boite dont l'hébergement sur serveur dédié ovh est la spécialité", c'est à elle de trouver le problème, car franchement avec un tel serveur , cela doit tenir le coup à moins que vous ayez 10000 visiteurs simultanés!

et Error Code: 2006 - MySQL server has gone away -> il y a un problème de config mysql. Il faut lancer les scripts que je vous ai indiqué. Maintenant, si vous ne savez pas lire les résultats, il faut voir avec la boite d'infogérance...

16

J'ai trouvé !!!! Tout seul comme un grand, pour un linux noob, j'suis trop content :wink:
Pour ceux que ça intéresse, à toutes fins utiles:

nano opcache.ini

remplacer
opcache.revalidate_freq = 60
par
opcache.revalidate_freq = 1

suivi du redémarrage du service:

service php5.6.24-fpm restart

Et voilà 100ms au lieu d'1 mn.... Ça me régle les deux problèmes. Celui du vidage de cache qui n'en finissait pas, et l'affichage du site après suppression récursif des dossiers tmp et local.

Merci à tous ceux qui sont venus me soutenir et essayer de m'aider à trouver une solution à ce problème sur lequel je bute depuis 4 jours...