Site Joomla fou...

[syl20ko]

Bonjour à tous,

Voici plusieurs années que je travaille avec Joomla et OVH mais aujourd'hui je n'ai pas trouvé de réponse à ce problème.

J'ai un site Joomla qui sature la base de données avec l'erreur max_user_connexion.

De plus, dans le panel OVH les statistiques du site montre que de nombreuses requêtes SQL sont effectuées. (statements à + 1million !!)

J'ai contacté plusieurs fois l'hébergeur, il n'a pas pu m'aider à résoudre le problème.

Dans le PhpMyAdmin, les statistiques sont également folles, 1.6To de transfert de données en 48h.

C'est un site simple, avec docman installé dessus. Le site est en version 3.8.13.

J'ai désactivé tous les plugins.

Avez-vous une idée ?

Savez-vous comment je peux visualiser les requêtes qui sont émises depuis le site Joomla ?

Merci d'avance !

[RobertG]

Bienvenue !

Pour moi, ça ressemble fort à des attaques sur ton site, par des robots. Tu peux voir dans les logs, depuis ton Manager, quelles sont les IP en cause et les bloquer ensuite par un deny dans ton .htaccess

[syl20ko]

Merci RobertG pour la réponse.

C'est très difficile à dire car en effet, l'analytics me prouve que beaucoup de visiteurs accèdent au site.

Les logs pour autant n'ont rien d'alarmant.

La seule hypothèse qu'il me reste c'est le log error (surement du à cause d'une offre business 2010 qui ne possède pas le PHP/FPM) :

AH10157: FastCGI: An error happend on Fastcgi processing, fallback to CGI
[Thu Oct 18 01:54:23 2018] [error] [client 178.255.215.91] [host www.monsite.com] Script timed out before returning headers: index.php
[Thu Oct 18 02:41:53 2018] [error] [client 178.255.215.91] [host www.monsite.com] AH10141: FastCGI: comm with server "/homez.650/site/www/index.php" aborted: idle timeout (300 sec)

En boucle !!!!

Existe t-il un moyen de récupérer sur un mutualisé les logs mysql ?

De nombreuse lignes (statements) sont retournées chaque jour sans pouvoir comprendre ce qui est fait.

C'est relativement frustrant !

[RobertG]

Ce sont les logs de connexion qui te donneront les infos dont je parle, avec les adresses des pages qu'ils tentent d'ouvrir.
Dans ton Manager, tu as plusieurs types de logs accessibles. Je n'ai jamais fait attention à d'éventuels logs mysql.

[syl20ko]

Merci une nouvelle fois RobertG.

Je viens de revérifier, il semblerait que ce ne soit pas la cause de mon problème.

En effet, ces ip sont les miennes, il n'y a pas d'autres ip (massives).

Cependant FastCGI ne semble pas activé sur cet ancien hébergement OVH.

Ces timeout font ralentir le serveur et les requêtes restent actives, ce qui entraîne un ralentissement, puis parfois, une chute du serveur.

Le fameux passage de FastCGI à CGI rend les performances du site Joomla 3 médiocres.

De plus, ce même site était hébergé sur un autre serveur OVH (récent) avant sa mise en place du son NDD officiel. il n'y avait aucune erreur de ce type pendant sa phase de développement.

Au passage, RobertG, si vous êtes le développeur de MoovJla alors je vous offre ma femme.

[RobertG]

Merci, mais j'en ai une ! Je ne suis que le successeur des auteurs de Moovla.

Il me paraît curieux que ce ne soient pas des attaques de robots qui fassent tant d'appels. Quant au timeout d'OVH, plus d'un s'en est plaint depuis un bon moment...

[daneel]

Bonjour,

1. Merci de tester avec l'activation du mode debug afin de déterminer le nombre de requêtes.
N'oubliez pas de desactiver le cache au préalable.



Je vous conseille d'éditer le plugin Système - Débogage (ou system debug )
pour afficher les erreurs uniquement pour les super admin en selectionnant superadmin dans "groupe autorisés" ou dans accès type.
Pour activer la fonctionnalité, c'est dans le menu système / configuration/ onglet système, débogage système à "oui"

Si votre site génère un bon nombre de requêtes par page, ce sera fortement ralenti (encore plus que d'habitudes) mais vous aurez une idée un peu plus précise. Vérifiez chaque plugin pouvant générer un nombre important de requêtes. Désactivez un par un ceux qui ne sont pas essentiel puis tester à nouveau. N'oubliez pas de desactiver temporairement le cache !

Les problèmes de requêtes sont parfois provoqué par de mauvais réglages. Par exemple, l'utilisation de ReReplacer de Regular Labs dans chaque page et à tous le contenu (modules et articles) a donné des ralentissement au chargement et des blocages de la part d'un hebergeur qui n'hésitait pas à brider l'accès (pour ne pas impacter les ressources pour les autres clients du même serveur).

2. La gestion du cache peut jouer également. Même inactive dans la configuration du site, elle peut être utilisé par certaines extensions pour éviter de générer de nombreuses requêtes. C'est le cas par exemple de virtuemart, de cck et autres extensions très appréciés. Si le cache joomla ne pose pas trop de problème, l'usage de cache alternatif serveur (memcached par exemple) peut provoquer des perturbations si la compatibilité n'est pas complète. C'était le cas par exemple sur ovh mutu (je n'ai plus testé depuis quelques années).

Donc je conseille de desactiver le cache, le temps de faire les tests nécessaire et de le vider même désactivé.

3. https : Parfois le certificat peut créer une boucle qui bloque le site comme c'est le cas avec l'utilisation de cloudflare ou cdn.

4. Dans le cas d'attaque par brute force, on aurai logiquement les traces dans le journal d'activité ( les log http du serveur).
La solution dans ce cas, c'est de bloquer les ip malveillants, d'instaurer une politique stricte sur les formulaires (recapcha, antispam, honeypot)
et de bloquer l'admin par un htpasswd ou d'une autre protection similaire. Depuis des années, j'utiliser cloudflare pour cacher l'adresse ip du serveur et bloquer ce type d'attaque avec succès. Tous les sites sont régulièrement scannés et subissent des attaques pouvant durer plusieurs heures/jours d'où la nécessité d'adopter de bonne règles de sécurité.

5. Un mauvais réglage du htaccess peut également ralentir ou bloquer le site notamment sur la réécriture, la redirection...
de préférence, utiliser le htaccess d'origine pour comparer.

6. Dans le cas d'un piratage, utiliser des outils d'analyse, vérifiez les logs et date de modification des fichiers et procéder au nettoyage.

Voilà, je pense avoir fait le tour des possibilités. Bon courage dans la résolution du problème.

Yann

[chabi01]

Bonjour,
J'avais également eu à gérer ce souci sur un site bridgé à forum via le plugin Fusion : cela provoquait le même type de souci.
Il n'y a pas ce type de plugin installé sur le site ?

Cordialement,