Bonjour,
Aujourd'hui, même constat :
https://tinyurl.com/2yuq7efr
le fichier slow_query de ce jour ne donne pas de query_time importants et surtout ne donne pas de surcharge vers 2h du matin ce matin ou vers 9h du matin ce matin.
Exemple log slow_query :
> > # Time: 2024-06-18T07:08:05.125348Z
> > # User@Host: root[root] @ localhost Id: 24268
> > # Query_time: 19.020357 Lock_time: 0.099818 Rows_sent: 0 Rows_examined: 0
> > SET timestamp=1718694466;
> > # Time: 2024-06-18T07:15:19.625095Z
> > # User@Host: root[root] @ localhost Id: 24268
> > # Query_time: 1.039831 Lock_time: 0.000000 Rows_sent: 90 Rows_examined: 365
> > SET timestamp=1718694918;
Nous avons par ssh désactivé plusieurs plugin hier :
https://tinyurl.com/28argddy
Peut-être désactiver encore d'autres plugins… on ne va tout désactiver tout de même et encore une fois un plugin qui sature la mémoire à partir de 2h du matin et qui la dépasse de 9h à 11h…
je ne comprends plus…
Nous sommes atteints par la même IP pendant 20 mn à partir de 2h05 au matin :
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:44 +0200] "GET /themes.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:45 +0200] "GET /about.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:47 +0200] "GET /wp-admin/css/colors/blue/CasperExV1.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (X11; Linux i686; rv:79.0) Gecko/20100101 Firefox/79.0"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:48 +0200] "GET /wp-content/index.php HTTP/1.1" 403 199 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0"
> 135.181.74.243 charentemaritime.1mouvement.orgmouvement.org - [18/Jun/2024:02:05:47 +0200] "GET /robots.txt HTTP/1.1" 200 141 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:48 +0200] "GET /byp.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:49 +0200] "GET /edit-comments.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:50 +0200] "GET /smm.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:51 +0200] "GET /cloud.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:52 +0200] "GET /wp.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:53 +0200] "GET /1.php HTTP/1.1" 301 25 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36"
> 138.199.18.68 1gm.orggm.org - [18/Jun/2024:02:05:54 +0200] "GET /classwithtostring.php H
Est-ce cela qui sature la mémoire ?
Le parefeu est activé au niveau de la config général php (7..4).
Merci pour vos retours.
Bonjour,
Impossible de dire plus à part analyser vos logs et vous limiter aux plugins essentiels.
Je sais par exemple que certaines option du plugins Wordfence sont très consommateurs de ressources et requête SQL (comme tout les plugins qui affirme faire du pare-feu applicatif d'ailleurs).
Idem pour l'IP que vous donnez celle-ci est classé comme mauvaise d'après plusieurs site et sur crowdsec elle est classé comme HTTP Scan/DoS/exploit ce qui ne doit certainement pas vous aider car cela utilise vos ressources de manière malveillante.
Note : le pare-feu que vous pouvez activer dans l'espace client ne va pas vous protéger de genre de bots qui fouillent les sites.
Cordialement, janus57
Bonjour,
Merci pour votre retour.
Bonjour,
après si vous voulez quand même avoir un plugin de sécurité, vous pouvez essayer des alternatives à wordfence, par exemple https://fr.wordpress.org/plugins/wp-simple-firewall/ car le discours commerciale (== présentation sur le site) semble prometteur.
Note : je ne suis pas affilié à ce site/éditeur, j'ai simplement vu qu'il ont un partenariat avec CrowdSec (Cf : https://www.crowdsec.net/blog/wordpress-protection-shieldpro-crowdsec).
Cordialement, janus57
Bonjour,<br />Merci pour votre message.<br />Ce matin à 9h : même phénomène, l'utilisation mémoire monte en flèche<br />Nous avons désactivé tous les répertoires en mettant "_DESACTIVE" au bout de chaque répertoire.<br />https://tinyurl.com/29a92gjn<br />comme pour le dossier "ffdepartement"<br />Ca n'a pas empêché la surcharge de la mémoire.<br />https://tinyurl.com/2587w2x2<br />Normalement, aucun Wordpress ne peut fonctionner puisque tous les sites sont bloqués car les répertoires sont "_DESACTIVE".<br />Incompréhensible.<br />Voici les erreurs que nous avons dans la log quand la mémoire est saturée :<br />> https://logs.cluster027.hosting.ovh.net/ifra-gm.org/osl/error/ifra-gm.org-19-06-2024.log#:~:text=%5BWed%20Jun%2019%2009%3A36%3A12%202024%5D%20%5Berror%5D%20%5Bclient,from%20server%20%22/homez.1680/ifragmorli/sites_fd/fd45/index.php%22
Bonjour,
Nous avons migré 15 sites (bdd) de la webcloud database vers une des bases du serveur principal.
Résultat : https://tinyurl.com/245qc7zg
un pic de saturation et connexion brefs vers 9h.
Mais d'où viennent ces connexions : de cette log (slow-query.log) avec des query_time très élevés ? :
> INSERT INTO `wpstg7_options` (`option_name`, `option_value`, `autoload`) VALUES ('_transient_doing_cron', '1718867954.4777209758758544921875', 'yes') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`);
> # Time: 2024-06-20T07:19:31.752449Z
> # User@Host: departement[departement] @ [10.27.21.130] Id: 15088
> # Query_time: 60.005867 Lock_time: 0.000005 Rows_sent: 0 Rows_examined: 0
> SET timestamp=1718867911;
> INSERT INTO `wpstg8_options` (`option_name`, `option_value`, `autoload`) VALUES ('_transient_doing_cron', '1718867911.7436010837554931640625', 'yes') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`);
> # Time: 2024-06-20T07:19:31.756751Z
> # User@Host: departement[departement] @ [10.27.20.164] Id: 14987
> # Query_time: 390.373829 Lock_time: 0.000007 Rows_sent: 0 Rows_examined: 0
> SET timestamp=1718867581;
> INSERT INTO `wpstg7_options` (`option_name`, `option_value`, `autoload`) VALUES ('_transient_doing_cron', '1718867581.3809709548950195312500', 'yes') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`);
> # Time: 2024-06-20T07:19:31.763391Z
> # User@Host: departement[departement] @ [10.27.20.164] Id: 14981
> # Query_time: 416.205411 Lock_time: 0.005749 Rows_sent: 0 Rows_examined: 0
Le problème viendrait de la saturation de la webcloud database ?
Le contenu de celle-ci est passé de 4 Go à 2 Go.
Ca a l'air de fonctionner mieux.
A suivre