sebwvs Posted February 18 Share Posted February 18 (edited) Bonjour à tous, Depuis quelques jours je reçois un avertissement de la part d'OVH pour dépassements de la mémoire vive "RAM" du serveur SQL Mail : Abus avec votre CloudDB "125 OOM kills detected during the last 24 hours. To avoid data corruption, please optimize your queries or upgrade to a bigger offer." Après quelques vérifications je vois que la taille de la BDD est passée de +/- 70mo à 580 mo je vérifie mes logs et je trouves des milliers d'entrées de ce type : plusieurs par minutes 47.128.46.122 photoflameng.com - [18/Feb/2024:09:00:56 +0100] "GET /img/m/76-small_default.jpg HTTP/1.1" 200 2306 "https://photoflameng.com/7-accessoires?page=3&q=Marque-Cullmann-GODOX-LEOFOTO-Lastolite-Lexar-Panasonic-SONY-SMALLRIG" "Mozilla/5.0 (Linux; Android 5.0) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; Bytespider; [email protected])" Je suppose donc que ce bot augmente d'une façon ou d'une autre massivement la taille de la BDD et ralentis également l’accès au site web. un avis ? une aide? *****************************edit***************************** je pense avoir compris l'augmentation de la taille de la BDD de 70m à 580m , en faite le bot Bytespider passe en revue toutes mes urls et notamment via le filtre à facette "Navigation à facettes" qui était configuré avec "Activer le système de cache" du coup ce cache grandit à vue d'oeil ! J'ai dans le module désactiver le système de cache et vider le cache et suis retombé à 58m ! Pour bloquer le bot Bytespider j'ai éditer mon htacces et ajouté un bout de code php dans l'index php à la racine en suivant la méthode de webbax> https://www.webbax.ch/2019/02/14/prestashop-1-7-boostez-hebergement-ep-69/ pour ceux qui aurait le même problème ... j'attend encore 2-3 jours et si ok j'éditerai ce post à résolut *****************************edit***************************** ***************************** Version de PrestaShop : 1.7.8.3 Informations du serveur : Linux #1 SMP Wed Nov 30 08:49:06 UTC 2022 x86_64 Version du logiciel serveur : Apache Version de PHP : 7.3.33 Limite de mémoire : 512M Temps maximal d'exécution : 165 Taille max. pour envoi de fichiers : 128M Version de MySQL : 5.7.42-log Moteur MySQL : InnoDB Connecteur MySQL : DbPDO **************************** Edited February 19 by sebwvs (see edit history) Link to comment Share on other sites More sharing options...
magicbel Posted February 18 Share Posted February 18 (edited) Bonjour, Pour comprendre déjà ce message, "OOM" veut dire "Out Of Memory" Il s'active pour tuer des process afin de garder le système en ligne car sans, c'est d'office la saturation complète. Dans votre cas, l'IP de l'exemple dans votre log est bien connue pour spammer le trafic comme un gros cochon En savoir plus ici sur l'origine de l'IP : https://www.crawl-tools.com/fr/whois-client/60ef49a3c8c37efac580e83402ab6505 Optez pour la manière radicale, un beau ban de la totalité de ce range et adieu les problèmes 47.128.0.0/16 Vous n'êtes pas le premier ni le dernier à rencontrer ce problème. Un client dernièrement avait le même souci (voir la charge avant le ban du range) Voyez si vous pouvez via l'interface d'OVH mettre en place un firewall ou autres (comme une règle iptables par exemple) afin de ban ce range d'ip. Edited February 18 by magicbel (see edit history) 1 Link to comment Share on other sites More sharing options...
sebwvs Posted February 18 Author Share Posted February 18 il y a 2 minutes, magicbel a dit : Bonjour, Pour comprendre déjà ce message, "OOM" veut dire "Out Of Memory" Il s'active pour tuer des process afin de garder le système en ligne car sans, c'est d'office la saturation complète. Dans votre cas, l'IP de l'exemple dans votre log est bien connue pour spammer le trafic comme un gros cochon En savoir plus ici sur l'origine de l'IP : https://www.crawl-tools.com/fr/whois-client/60ef49a3c8c37efac580e83402ab6505 Optez pour la manière radicale, un beau ban de la totalité de ce range et adieu les problème 47.128.0.0/16 Vous n'êtes pas le premier ni le dernier à rencontrer ce problème. Un client dernièrement avait le même souci (voir la charge avant le ban du range) Voyez si vous pouvez via l'interface d'OVH mettre en place un firewall ou autres (comme une règle iptables par exemple) afin de ban ce range d'ip. Bonjour magicbel, et merci pour la confirmation ... le plus étrange est que sur mon serveur OVH j'ai bien un firewall (non paramétrable)activé ! depuis mon post ici, j'ai fait plusieurs recherches et je pense avoir trouver une solution ... j'ai trouvé chez webbax > https://www.webbax.ch/2019/02/14/prestashop-1-7-boostez-hebergement-ep-69/ j'ai édité le htacces pour bloquer les robots connus et j'ai édité également le fichier « index.php » à la racine avec un bout de code pour le blocage de certain user agent ainsi que l’écriture d'un fichier log simplifié qui me confirme le blocage du ou des bots ... je viens juste de terminer ... j'ai nettoyé ma BDD avec le module Prestashop Optimizer tout à l'air de fonctionner pour le moment... j'éditerais mon post à résolu dans 2-3 jours quand ça serra confirmé ! merci Link to comment Share on other sites More sharing options...
sebwvs Posted February 19 Author Share Posted February 19 *****************************edit***************************** je pense avoir compris l'augmentation de la taille de la BDD de 70m à 580m , en faite le bot Bytespider passe en revue toutes mes urls et notamment via le filtre à facette "Navigation à facettes" qui était configuré avec "Activer le système de cache" du coup ce cache grandit à vue d'oeil ! J'ai dans le module désactiver le système de cache et vider le cache et suis retombé à 58m ! Pour bloquer le bot Bytespider j'ai éditer mon htacces et ajouté un bout de code php dans l'index php à la racine en suivant la méthode de webbax> https://www.webbax.ch/2019/02/14/prestashop-1-7-boostez-hebergement-ep-69/ pour ceux qui aurait le même problème ... j'attend encore 2-3 jours et si ok j'éditerai ce post à résolut *****************************edit***************************** Link to comment Share on other sites More sharing options...
Mediacom87 Posted February 19 Share Posted February 19 il y a 51 minutes, sebwvs a dit : J'ai dans le module désactiver le système de cache et vider le cache et suis retombé à 58m ! Vous pouvez programmer une tâche cron pour vider automatiquement le cache de ce module, ce qui peut éviter ce genre de problème de saturation de base. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now