Neu Suche Lösung! (mit Finderlohn!) - überfüllter phptmp Ordner.

[Neuling88]

Hallo zusammen,

ich habe folgendes riesen Problem und wäre sogar bereit demjenigen der mir helfen kann XXX EUR zu zahlen. Das soll jetzt nicht unseriös klingeln, aber es ist so eine LAST!
Das Problem ist, dass auf meinem FTP ein phptmp Ordner existiert, der sich ständig / sekündlich mit session Dateien füllt (60-100 Dateien pro Minute) . Größe: 4000-8000 Bytes,
dazwischen auch mal 50.000 oder 90.000 Bytes. Natürlich ist dann irgendwann der Speicher voll oder überlastet. Hier im Forum findet man einen alten Thread ( Shop 3) in dem mal
1-2 Leute das selbe Problem hatten - jedoch ohne definitiven Lösungsvorschlag.

Der Hoster sagt: Viele Bots, Crawler Zugriffe, daneben Doofinder der Artikel durchscannt, Google, Bingbots, Google Analytics Plugin, usw. usw.

Soweit ich es einschätzen kann, aber alles / vieles "normal". Google Bots durchforsten ständig das Internet und Doofinder ist ein seriöses, beliebtes Tool, 1000fach im Einsatz. Letztes Mal
haben wir SEO Maßnahmen in Auftrag gegeben, als dann 1-2 Scans auf der Seite gemacht wurden ging gar nichts mehr, weil es dann noch mehr Zugriffe / Tests gab. Diese Maßnahmen von
SEO Unternehmen für einen IST Zustand sind doch aber auch ganz normal!?

Es gibt eine:
session.gc_maxlifetime = 1440

1440 seconds = 24 minutes

Das hilft nur nichts, da die Dateien ja viel schneller anwachsen. Natürlich können wir den Ordner auch mit Cronjobs leeren lassen. Das Problem: Er ist dann immer ganz leer und echte eingeloggte Nutzer mit
Waren im Warenkorb werden rausgeworfen. Manuell lösche ich den ganzen Tag tausende Files (außer die letzte Stunde) um aktive Nutzer nicht zu stören. Aber das kann ja kein Dauerzustand sein.

Wir haben einen dedicated Server (VPS Cloud) der nicht mit anderen Kunden geteilt wird mit eigen Betriebssystem und eigener IP Adresse (ich selbst habe 0 Ahnung, aber das ist das was wir haben).

Wer traut sich zu hier weiterhelfen zu können oder sich mal session Dateien anzuschauen und evtl. den Verursacher rauszufinden? Der Hoster meinte auch, dass es evtl. veraltete Software / Plugins sein können etc.,
aber wir haben jetzt den neuen Shop 5 und wirklich nur ganz wenige Plugins am laufen.

 

[mh1]

...Hier im Forum findet man einen alten Thread (Shop 3) in dem mal 1-2 Leute das selbe Problem hatten - jedoch ohne definitiven Lösungsvorschlag.

Falls du diesen Thread meinst: https://forum.jtl-software.de/threa...ion-dateien-in-phptmp-bug.37363/#post-1028173
Dort steht doch eine mögliche Lösung, sogar mit konkretem Link zum PHP Manual
Und so furchtbar alt ist der Thread ja auch nicht (meine letzter Beitrag war gestern vormittag)

...Natürlich können wir den Ordner auch mit Cronjobs leeren lassen. Das Problem: Er ist dann immer ganz leer und echte eingeloggte Nutzer mit
Waren im Warenkorb werden rausgeworfen. Manuell lösche ich den ganzen Tag tausende Files (außer die letzte Stunde) um aktive Nutzer nicht zu stören. Aber das kann ja kein Dauerzustand sein.

Da du ja schreibst, dass du dich mit der Conjob Lösung anfreunden könntest, aber keine aktiven User löschen willst, könntest du doch nur die Dateien, die älter sind als eine Stunde von dem Cronjob löschen lassen (also dieselbe Auswahl, die du ja auch bei deinen manuellen Löschvorgängen machst): find /foo/bar/phptmp -daystart -maxdepth 1 -mmin +59 -type f -name "*.session" -exec rm -f {} \;. Aber bevor man so einen Cronjob einrichtet, sollte man den Befehl gründlich testen (und vorallem vor das rm ein echo schreiben).


EDIT:
Der find Befehl ist aber nur als Beispiel anzusehen. Ich weiß ja nicht, welches Betriebssystem du auf deinem Server hast bzw. welche Befehle/Tools dort zur Verfügung stehen.

 

[FMoche]

Du kannst auch probieren, in der includes/config.JTL- Shop.ini.php die Zeile

define('SAVE_BOT_SESSION', 3);

einzufügen.
Das sollte dafür sorgen, dass für erkannte Bots keine Session gespeichert wird.
Das sollte zumindest für die meisten Suchmaschinen helfen. Wie das bzgl. Doofinder aussieht, kann ich leider nicht sagen, weil ich nicht weiß, wie da der Useragent-String aussieht.

 

[Neuling88]

Falls du diesen Thread meinst: https://forum.jtl-software.de/threa...ion-dateien-in-phptmp-bug.37363/#post-1028173
Dort steht doch eine mögliche Lösung, sogar mit konkretem Link zum PHP Manual
Und so furchtbar alt ist der Thread ja auch nicht (meine letzter Beitrag war gestern vormittag)



Da du ja schreibst, dass du dich mit der Conjob Lösung anfreunden könntest, aber keine aktiven User löschen willst, könntest du doch nur die Dateien, die älter sind als eine Stunde von dem Cronjob löschen lassen (also dieselbe Auswahl, die du ja auch bei deinen manuellen Löschvorgängen machst): find /foo/bar/phptmp -daystart -maxdepth 1 -mmin +59 -type f -name "*.session" -exec rm -f {} \;. Aber bevor man so einen Cronjob einrichtet, sollte man den Befehl gründlich testen (und vorallem vor das rm ein echo schreiben).


EDIT:
Der find Befehl ist aber nur als Beispiel anzusehen. Ich weiß ja nicht, welches Betriebssystem du auf deinem Server hast bzw. welche Befehle/Tools dort zur Verfügung stehen.

Die sagen da es schon so eine hohe Last auf der Seite gibt, wäre das checken von "Zeiten" zum löschen > 1 Stunde auch zu einer Überlast führen. Ich kopiere mal ein paar Zeilen ein:

ZITAT:
Das leeren des Ordners dauert an sich schon lange und diese Operation erhöht nochmals die Systemlast, wenn man also ein Script programmiert was zusätzlich die Zeitstempel prüft wird dadurch noch mehr Last erzeugt und es werden sehr viel mehr Session Dateien erhalten bleiben als jetzt.

Die Sessions bzw. besser gesagt Seitenaufrufe uns Suchabfragen werden zu ca. 80% nur durch Crawler und Bots erzeugt.

Dadurch wird eine System Überlast erzeugt die in den Spitzen bei 100 bis sogar 200% liegt.

ZITAT2:
Nein, die Cronjobs sind nur als Notlösung gedacht.

Sie müssen die automatisierten Zugriffe von den SEO Bots wieder loswerden.

Also die robots.txt und htaccess verwenden um diese auszusperren und Abfragen der Datenbank zu optimieren, weniger Optionen zum filtern, Statistiken deaktivieren etc.

ZITAT3:
Wenn Sie das Problem mit den Bots nicht sofort lösen können, dann brauchen Sie ein System welches sehr hohe Systemresourcen hat und von jemandem managed wird.

Also ein Root System was sehr viele Rechenintensive Anfragen verarbeiten kann.



Allerdings ist dies auch keine Garantie das ein dedicated Root Server das auf Dauer schafft die Last zu bewältigen.

Es gibt viele Anbieter, wichtig dabei ist das es ein echter Root Server ist der managed wird z.b. ....

 

[Neuling88]

Du kannst auch probieren, in der includes/config.JTL- Shop.ini.php die Zeile

define('SAVE_BOT_SESSION', 3);

einzufügen.
Das sollte dafür sorgen, dass für erkannte Bots keine Session gespeichert wird.
Das sollte zumindest für die meisten Suchmaschinen helfen. Wie das bzgl. Doofinder aussieht, kann ich leider nicht sagen, weil ich nicht weiß, wie da der Useragent-String aussieht.

@FMoche WOW DANKE. Das scheint zu funktionieren. Jetzt sind aus 60 pro Minute 1-5 pro Minute geworden.

 

[css-umsetzung]

wenn du das hier noch in deine config Datei vom Shop einfügst, dann bist du auch die schädlichen Bots los die einfach nur Ressourcen fressen

if(preg_match("/Mb2345Browser|LieBaoFast|Seekport|SemrushBot|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot/",$_SERVER['HTTP_USER_AGENT'])) {
    header('HTTP/1.0 403 Forbidden');
    die("zugriff nicht erlaubt");
}

 

[Neuling88]

wenn du das hier noch in deine config Datei vom Shop einfügst, dann bist du auch die schädlichen Bots los die einfach nur Ressourcen fressen

if(preg_match("/Mb2345Browser|LieBaoFast|Seekport|SemrushBot|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot/",$_SERVER['HTTP_USER_AGENT'])) {
    header('HTTP/1.0 403 Forbidden');
    die("zugriff nicht erlaubt");
}

Super, danke. Wäre ScreamingFrog evtl. auch noch so etwas? Oder sind die "ok"? @css-umsetzung

 

[css-umsetzung]

das muss jeder für sich entscheiden was man zusätzlich einbindet.
ScreamingFrog ist ja ein SEO Crawler, du weißt ja selbst am besten ob du den aktiviert hast, wenn nicht dann aussperren...

 

[Neuling88]

das muss jeder für sich entscheiden was man zusätzlich einbindet.
ScreamingFrog ist ja ein SEO Crawler, du weißt ja selbst am besten ob du den aktiviert hast, wenn nicht dann aussperren...

@css-umsetzung Habe Dir mal noch privat geschrieben. Danke jedenfalls für Deine Hilfe. Hoffe Du kannst mir noch den letzten, entscheidenen Hinweis geben

 

[Neuling88]

Hatte diesen Link bei mir drin und er hat immer gut geholfen. Nun hatte ich aber ein Error deswegen und konnte keinen Abgleich mehr machen. Nach löschen des Codes geht dies wieder. Von 0 auf Gleich nach 1 Jahr.
Was kann das sein?

 

[css-umsetzung]

Hatte diesen Link bei mir drin und er hat immer gut geholfen. Nun hatte ich aber ein Error deswegen und konnte keinen Abgleich mehr machen. Nach löschen des Codes geht dies wieder. Von 0 auf Gleich nach 1 Jahr.
Was kann das sein?

was für einen Link?

 

[Neuling88]

was für einen Link?

Den von Dir. Sorry, nicht Link, sondern CODE:

PHP:
if(preg_match("/Mb2345Browser|LieBaoFast|Seekport|SemrushBot|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot/",$_SERVER['HTTP_USER_AGENT'])) {
header('HTTP/1.0 403 Forbidden');
die("zugriff nicht erlaubt");
}

 

[css-umsetzung]

Das verursacht aber keinen error, es gibt glaube ich max ein Warning wenn die Servervariable leer ist, das sollte man am besten noch mit !empty() abfragen um sicher zu sein.

if(!empty($_SERVER['HTTP_USER_AGENT']) && preg_match("/Mb2345Browser|LieBaoFast|Seekport|SemrushBot|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot/",$_SERVER['HTTP_USER_AGENT'])) {
header('HTTP/1.0 403 Forbidden');
die("zugriff nicht erlaubt");
}

 

[Neuling88]

Das verursacht aber keinen error, es gibt glaube ich max ein Warning wenn die Servervariable leer ist, das sollte man am besten noch mit !empty() abfragen um sicher zu sein.

if(!empty($_SERVER['HTTP_USER_AGENT']) && preg_match("/Mb2345Browser|LieBaoFast|Seekport|SemrushBot|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot/",$_SERVER['HTTP_USER_AGENT'])) {
header('HTTP/1.0 403 Forbidden');
die("zugriff nicht erlaubt");
}

Habe den jetzt mal nochmal eingefügt und das scheint soweit zu gehen. Vorher ging es aber jetzt auch 1 Jahr lang. Und auf einmal... (5 Stunden vorher noch einen Abgleich gemacht),
flutschte der Abgleich so durch und im Log gab es folgenden Error:

Der Abgleich wurde abgebrochen. Alle im Abgleich entstandenen Fehler finden Sie im Logbuch.
<br />
<b>Notice</b>: Undefined index: HTTP_USER_AGENT inXXXXXXXXX/config.JTL- Shop.ini.php</b> on line <b>26</b><br />
0;JTL4;501;<br />
<b>Notice</b>: Undefined index: HTTP_USER_AGENT in <b>/XXXXXXXXs/config.JTL-Shop.ini.php</b> on line <b>26</b><br />
0;JTL4;501;


(die XXXe habe ich mal gerade selbst eingefügt, ist unsere URL / Pfad etc.) Aber genau in dieser Zeile 26 war der Code... als ich ihn dann rausnahm, ging es wieder.

PS: Wer bist Du überhaupt? Wir können ja mal zusammenarbeiten !? Brauche öfters mal Hilfe bei Dingen.

 

[css-umsetzung]

Das ist ja auch kein Error, das ist eine Notice Meldung und es ging so lange gut, bis jemand auf die glorreiche Idee kam, bei dir, in der Config Datei vom Shop das error_reporting zu aktivieren (dem solltest du mal auf die Finger klopfen und darum bitten das wieder zu deaktivieren, denn das hat im Live Betrieb nichts zu suchen)

https://guide.jtl-software.com/jtl-...-jtl-shop-abgleich-angezeigt-was-soll-ich-tun

PS: Wer bist Du überhaupt? Wir können ja mal zusammenarbeiten !? Brauche öfters mal Hilfe bei Dingen.

Wie jetzt, ich bin die css-umsetzung , da gebe ich mir solche Mühe bekannt zu werden
Jeder kann mich buchen....