Base de données qui grossit tres vite

[flou81]

Bonjour

Ce matin, mail d'OVH ( pour mes deux sites joomla) qui me dit que ma base de donnée est à 80%, puis mail aussitôt derrière pour me dire qu'elle est pleine et que je dois faire quelque chose ou prendre un hébergement plus grand. Coup de téléphone chez eux,: ils ne savent pas de quoi cela provient ! Piratage de mon site ou un scrip qui se lance en boucle. Joomla et les extensions sont à jour ! Je passe mes fichiers au crible et je ne trouve rien. Comment puis je voir si un script se lance tout seul ou tourne en boucle ? ...et tout cela arrive depuis que je viens de faire la mise à jour de Joomla 3.8.5.
Auriez vous une idée?

Hop là , je viens de trouver , je pense, en fouillant sur le site : mettre la méthode de session en php

[lomart]

Bonsoir,

Il faut déjà regarder avec phpmyadmin, les tables qui ont pris du poids.
Quand on est sur la liste des tables, il suffit de cliquer sur le titre de la colonne taille pour les voir

[RobertG]

S'il s'agit bien de la table "sessions" comme le suggère la fin du message, il ne faut pas oublier de la vider après être passé en mode PHP

[jfque]

C'est intéressant ce passage en PHP pour les sessions.
Cela dit, si la table sessions est bien celle qui se remplit trop vite, il n'est cependant pas normal qu'elle "explose" en terme de taille. Cela peut indiquer, soit un mauvais paramétrage (durée de sessions trop longues) soit un trafic "trop" important dû à des attaques de hackers que vous devriez repousser avec quelque chose comme Admin Tools Pro. Si toutefois il s'agit d'un trafic légitime (votre site a du succès), vous devriez ajuster son hébergement en fonction. La taille de la base de données ne devrait pas vous limiter.

[RobertG]

Non, c'est une modification de la gestion de ce nettoyage qui est en cause, il y a une discussion sur Github, citée dans cette discussion https://forum.joomla.fr/node/1975110, qui conseille ce passage en PHP ou l'utilisation d'un fichier lancé par cron. Si j'ai bien compris, ce fichier ne sera pas disponible en 3.8 mais seulement à partir de la 3.9

[jfque]

Effectivement, je vois des centaines d'entrées dans la table sessions des sites de mes clients ! Merci pour le tuyau.

[flou81]

S'il s'agit bien de la table "sessions" comme le suggère la fin du message, il ne faut pas oublier de la vider après être passé en mode PHP

Bonjour

Je suis allé voir sur un de mes sites et la base est redevenue "normale" sans y toucher. Mais je vais veiller à ton conseil.
Merci encore !!

[GraphiqueDesign]

S'il s'agit bien de la table "sessions" comme le suggère la fin du message, il ne faut pas oublier de la vider après être passé en mode PHP

Bonjour RobertG
D'habitude, je comprends assez bien tes conseils qui sont toujours très clairs mais là, je suis largué.
Ayant le même soucis de la base sessions qui gonfle, tu préconises de passer en mode PHP. Peux tu me dire quoi faire pour passer quoi en mode PHP ?
Je te remercie mille fois.

[RobertG]

Dans le fichier configuration, par ftp remplacer public $session_handler = 'database'; par public $session_handler = 'none', puisque tu n'accèdes pas à l'administration;
Par phpMyAdmin, repérer la table "#__session" et cliquer sur "vider". Peut-être se viderait-elle seule, mais je n'en suis pas certain.

[GraphiqueDesign]

Dans le fichier configuration, par ftp remplacer public $session_handler = 'database'; par public $session_handler = 'none', puisque tu n'accèdes pas à l'administration;
Par phpMyAdmin, repérer la table "#__session" et cliquer sur "vider". Peut-être se viderait-elle seule, mais je n'en suis pas certain.

Merci Robert !
Mais comme j'ai retrouvé l'accès à mon administration, en version soft, ça donne :
Configuration > Système > Configuration des sessions > Méthode > PHP

Tu confirmes ?
Ça change beaucoup de choses dans le fonctionnement du site ?
Merci Robert.

[RobertG]

Oui, c'est ce qu'il faut faire.
Je ne me suis pas posé la question de savoir si ça change quelque chose au fonctionnement ! Sûrement cependant au niveau de la gestion des sessions qui sont enregistrées dans des fichiers, mais il y a toujours ajout d'enregistrements dans la base, le nettoyage de celle-ci étant plus efficace.

La seule solution pour éviter de saturer cette table session étant de passer en mode PHP ou de lancer un cron, j'ai choisi la première méthode, plus simple que de récupérer le script sur Github, le placer sur tous les sites gérés et y définir un cron.

Ce que j'ai du mal à comprendre par contre, c'est la gestion des fichiers de gestion et la fréquence de leur suppression.

[jfque]

Pour le "nettoyage" des fichiers, cela dépend de la configuration de PHP.
Il faut aller voir dans les informations système, l'onglet "Informations PHP". Là, il faut regarder (dans le bas de la page) les paramètres du module "Session".
Voir tout d'abord si le module est activé : Session Support = enabled (à ma connaissance, il est toujours activé).
Ensuite, les 2 paramètres cruciaux sont : session.gc_divisor et session.gc_probability.

Si session.gc_probability est réglé sur 0, ça veut dire qu'il n'y a pas de nettoyage des "déchets" PHP (GC veut dire "garbage collection"). En clair cela veut dire que les sessions expirées ne seront pas effacées. En pratique donc, au lieu que ce soit la base de données qui grossit de façon non contrôlée, c'est votre dossier /tmp (attention, ce n'est pas le dossier /tmp de l'installation Joomla!, c'est celui de votre hébergement, en général un niveau au-dessus de la racine accessible via http). En général comme les hébergement sont plutôt généreux en espace disque, cela peut ne pas être un problème mais je ne sais ce qu'il en est d'avoir un dossier avec des milliers (dizaines ? centaines ?) de fichiers.

Sur un hébergement mutualisé, il n'est pas sûr de pouvoir régler session.gc_probability sur autre chose que 0.
Comme je gère mes propres serveurs, je l'ai réglé sur 50. Un calcul basé sur le rapport session.gc_probability/session.gc_divisor donne en fait une probabilité de 5% d'un nettoyage des sessions expirées à chaque fois qu'une nouvelle session est créée. Je vais voir si ce réglage garde la taille du dossier sous contrôle.

[RobertG]

Merci de ces précisions !

Je viens de vérifier le serveur de mon client et le mien (a priori exactement les mêmes). Sur les deux, gc_divisor est à 1000, gc_probability à 1. Par contre, gc_maxlifetime est à 900 sur le sien, à 9000 sur le mien. Je n'ai pas cherché à savoir si ces valeurs peuvent être modifiées par l'utilisateur sur ce type de serveur.

[Bmzen]

Bonjour,
Débutant, j'ai suivi le conseil de passer ne PHP ayant moi aussi reçu un mail d'OVH pour me signaler que j'arrivai à 80%. le souci c'est que désormais je n'arrive plus à accéder à l’administration du site. j'obtient un 504Gateaway time out par contre le site reste lui accessible.
Auriez vous un conseil à me donner ?

Dois je me diriger vers une restauration d'après vous ?
Merci de m'aider

Fausse alerte sans rien faire je viens de pouvoir y accéder.

[manu93fr]

Hello
le "504Gateaway" est un serveur surchargé ... si la table est toujours bien rempli (la table session ...) tu peux la vider directement via phpmyadmin ... mais attention de ne pas te tromper de ligne