Neu Hohe CPU-last auf Shopserver - JTL Shop Query?

[AWo]

Hallo,

wir sehen seit ca. 2 Monaten eine hohe CPU-Auslastung auf unserem JTL- Shop Server (Linux, Ubuntu 22 LTS, 32 GB RAM, 6 Cores). Dort laufen neen dem Shop auch einige Wordpress-Instanzen.

Seit den angesprochenen 2 Monaten bekommen wir vom Server Monitoring mehrfach am Tag Alarme, dass die CPU zu 100% ausgelastet ist, der System-Monitor-Graph bestätigt das, eben so "top" und "htop". Die Auslastung geht gem. '(h)top' auf Kosten der mariadb. Daraufhin haben wir mit der SQL Workbench nachgesehen und alle Top-Auslatungsqueries kommen vom JTL Shop. Der Spitzenreiter mit Abstand ist diese Query hier:

SELECT MAX ( `ssMerkmal` . `fMax` ) AS `fMax` , MIN ( `ssMerkmal` . `fMin` ) AS `fMin` FROM ( SELECT `ROUND` ( `LEAST` ( ( `tpreisdetail` . `fVKNetto` * ? ) * ( ( ? - `GREATEST` ( `IFNULL` ( `tartikelkategorierabatt` . `fRabatt` , ? ) , ?, ... ) ) / ? ) , `IFNULL` ( `tsonderpreise` . `fNettoPreis` , ( `tpreisdetail` . `fVKNetto` * ? ) ) ) * ( ( ? + ? ) / ? ) , ? ) AS `fMax` , `ROUND` ( `LEAST` ( ( `tpreisdetail` . `fVKNetto` * ? ) * ( ( ? - `GREATEST` ( `IFNULL` ( `tartikelkategorierabatt` . `fRabatt` , ? ) , ?, ... ) ) / ? ) , `IFNULL` ( `tsonderpreise` . `fNettoPreis` , ( `tpreisdetail` . `fVKNetto` * ? ) ) ) * ( ( ? + ? ) / ? ) , ? ) AS `fMin` FROM `tartikel` JOIN ( SELECT DISTINCTROW `kArtikel` FROM `tartikelmerkmal` WHERE `kMerkmalWert` = ? ) AS `tmerkmaljoin` ON `tmerkmaljoin` . `kArtikel` = `tartikel` . `kArtikel` JOIN `tartikelmerkmal` ON `tartikel` . `kArtikel` = `tartikelmerkmal` . `kArtikel` JOIN ( `tpreis` JOIN `tpreisdetail` ON `tpreisdetail` . `kPreis` = `tpreis` . `kPreis` AND `tpreisdetail` . `nAnzahlAb` = ? )

Sie wird von allen Queries am häufigste ausgeführ und dauert immer am längsten.

Kann jemand etwas dazu sagen? Ist das für die Statistiken, die ich im Shop-Admin-Bereich sehe?

Gruß
AWo

 

[css-umsetzung]

Du hast Bot Besuch und der wird dir wenn du nicht etwas dagegen tust, die Seite über kurz oder lang lahmlegen.

Die Lösung die hier gepostet wurde, reicht mittlerweile nicht mehr aus, aber ich kann, wenn es wie ich erwarte Bots sind, helfen.

https://forum.jtl-software.de/threads/sehr-hohe-cpu-last-durch-db.214318/

 

[AWo]

Ich ahnte es....Danke.

Wo kommt der Code-Schanipsel denn hineinrein?

Gruß
AWo

 

[css-umsetzung]

Der nutzt dir nichts mehr, da die mittlerweile ohne Kennung kommen, es sollte also zuerst geprüft werden, was bei dir da so Alarm macht.

 

[AWo]

So, zwei Adressbereiche ausfindig gemacht, die permanent über den Shop rennen. Erst musste ich den Apache geschwätziger machen, dann konnte ich die Adressen identifizieren und per .htaccess blocken. Siehe da, waren bis jetzt die mariadb-Prozesse auf den ersten tausend Plätzen bei der Auslastung vertreten, läuft es jetzt wie vorher und mariadb ist nicht mehr führend, sondern es wechselt jetzt bunt durch.

Das soll für heute Abend reichen....mehr später...

Danke & Gruß
AWo

 

[css-umsetzung]

Irgendwann kommen die mit so vielen unterschiedlichen IP Adressen, so das du das nicht mehr in den Griff bekommst.
Das ist also alles nur eine Momentaufnahme.

Mit diesem Schnipsel in der config.ini vom Shop (einfach am Ende einfügen) siehst du ganz gut was da wirklich los ist. Es werden im jtllogs Verzeichnis die einzelnen Zugriffe Tagesabhängig festgehalten.

$writeLog = true;
if (!empty($_SERVER['HTTP_USER_AGENT'])) {
    $agent = $_SERVER['HTTP_USER_AGENT'];
} else {
    $agent = "unknown";
}

if (!empty($_SERVER['HTTP_REFERER']) && !preg_match("/google/", $_SERVER['HTTP_REFERER'])) {
    $referer = $_SERVER['HTTP_REFERER'];
} else {
    $referer = "Keine Herkunft";
}


$cssUri = str_replace("shop/", "", $_SERVER['REQUEST_URI'] ?? "/");
$cssIP = $_SERVER['REMOTE_ADDR'] ?? "localhost";
date_default_timezone_set('Europe/Berlin');

if ($writeLog && ($fp = fopen(PFAD_ROOT . "jtllogs/zugriffslog_" . date("d-m-Y") . ".log", "a+"))) {
    fwrite($fp, date("H:i:s") . "\t" . $cssIP . "\t\t" . $agent . "\n");
    fwrite($fp, "HTTP_REFERER:\t" . $referer . "\n");
    fwrite($fp, URL_SHOP . $cssUri . "\n");
    fwrite($fp, "---------------------------------------------------------------------------------\n");
    fclose($fp);
}

 

[AWo]

Hey! Danke!

ich kenne das Problem schon von meinem Foren und meinen Online-Magazinen....

Seit ich gestern angefangen habe zu blocken...mal sehen was da noch kommt...



Gruß
AWo

 

[css-umsetzung]

Wie ich schon schrieb,
Sich an IP Adressen zu orientieren ist ein Kampf gegen Windmühlen und wenn du nicht aufpasst sperrst du wichtige Suchmaschinen oder eventuelle Kunden.

 

[tafechner]

Hatten wir auch bei unseren Kunden. Wir setzen auf NGNIX und eigenem Webadministrationstool und haben böse bots und IPs gesperrt.
Ansonsten setzen wir einige scripte auf unseren Servern ein, die die Bots und IP die zu hohe Last verursachen zeitweise rausschmeißen aber eben nicht ausschließlich.

Wir haben eigene Server im DE FF/Main Rechenzentrum https://webspeicher.online

 

[AWo]

Hatten wir auch bei unseren Kunden. Wir setzen auf NGNIX und eigenem Webadministrationstool und haben böse bots und IPs gesperrt.
Ansonsten setzen wir einige scripte auf unseren Servern ein, die die Bots und IP die zu hohe Last verursachen zeitweise rausschmeißen aber eben nicht ausschließlich.

Wir haben eigene Server im DE FF/Main Rechenzentrum https://webspeicher.online

Ja, das ist mir klar....und da kann ich unterscheiden...

Gruß
AWo
35+ Jahre Voll-IT'ler