Hallo zusammen,
habe bei einem Projekt festgestellt, dass das Verzeichnis /var/cache/prod/http_cache immer schwerer wurde, bis über 30GB.
Was kann ich da falsch eingestellt haben beim caching?
Viele Grüße,
conter
Druckbare Version
Hallo zusammen,
habe bei einem Projekt festgestellt, dass das Verzeichnis /var/cache/prod/http_cache immer schwerer wurde, bis über 30GB.
Was kann ich da falsch eingestellt haben beim caching?
Viele Grüße,
conter
Vermutlich wird der Cache mit vielen GET Parameter vollgefüllt. Dazu müsste man sich die Cache files ansehen und analysieren.
Hmm, bin ein bisschen überfordert
Anhang 21664
Das cache/prod Verzeichnis enthält ja eine Vielzahl von Dateien ...
Wo müsste ich ansetzen?
Die Website hat zwar über 100 Seiten ist aber im großen und ganzen nur Präsentation von Text und Bild.
Wo könnten get-Variablen herkommen? Habe eigentlich nur Kontaktformulare.
Viele Grüße,
conter
Es geht um den Ordner /var/cache/prod/http_cache
GET Variablen kann jeder Besucher oder Bot beliebig setzen.
Und die Seiten mit den Parametern kommen dann in den Cache? Oha, da liesse sich ja praktisch jede Website problemlos lahmlegen, indem man die Seiten mit unterschiedlichen Parametern aufruft solange bis der Webspace voll ist.
es gibt im Ordner "http_cache" zwei Unterordner:
"md" da ist so bot-Kram drin
"a:1:{i:0;a:2:{i:0;a:5:{s:10:"user-agent";a:1:{i:0;s:75:"Mozilla/5.0 (compatible; SemrushBot/2~bl; +http://www.semrush.com/bot.html)";}s:10:"connection";a:1:{i:0;s:5:"close" ;}s:15:"accept-encoding";a:1:{i:0;s:12:"gzip,deflate";}s:6:"accep t";a:1:{i:0;s:9:"text/html";}s:4:"host";a:1:{i:0;s:20:"www.teppich-stark.de";}}i:1;a:15:{s:13 ..."
und
"en" das sind in weiteren Unterordnern zahlreiche Dateien die alle beginnen mit
"<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<title>404 Seite nicht gefunden ... </title>"
Das heißt wohl, dass trotz Weiterleitung der alten URLs in der htaccess immer noch viele 404er auflaufen.
In den Logs sind die Fehler aber nicht zu sehen.
404 Seiten sollten nicht gecached werden, evt. existiert da ein Fehler innerhalb von Contao. Wenn du das reproduzieren kannst, würde ich das als Fehler melden.
... der Fehler sitzt wahrscheinlich hier an der Tastatur ...
Ich habe den Cache im Startpunkt aktiviert und auf der 404 und 403 Seite nicht überschrieben.
Habe ich jetzt nachgeholt und hoffe, dass es jetzt damit erledigt ist.
Danke für eure Hilfe!
Wenn du das in einer frischen Contao 4.4.30 Installation reproduzieren kannst, dann würde ich das auf Github als Fehler melden. Ich denke nicht, dass die angezeigte 404 Seite für beliebige URLs gecached werden sollte - andernfalls füllt das den http cache drastisch bei Botanfragen.Zitat:
Zitat von conter
Ich habe das System eben auf 4.4.30 aktualisiert.
Mal schauen, was über Nacht reinkommt.
Sollte da noch was sein, melde ich mich noch mal.
Ich habe in einer anderen Testumgebung eine frische 4.4.30. Da ist der http_cache noch leer.
Wie soll ich versuchen, das Verhalten zu reproduzieren?
Caching hab ich genau so eingestellt wie auf meiner Seite oben.
Viele Grüße,
conter
Einfach eine x-beliebige URL aufrufen, die nicht existiert, sodass Contao die 404 Seite anzeigt.Zitat:
Zitat von conter
Der http_cache der nackten Testinstallation enthält wieder diese zwei Ordner md und en.
In md liegt nur eine gecachte Startseite und keine gecachte 404-Seite.
Viele Grüße,
conter
Auch meine Website mit den 30 GB Cache ist jetzt ruhig :)
Keine 404er mehr im http_cache.
Aber nun nur, weil du die Caching Einstellung in der 404 Seite überschrieben hast, oder einfach, weil du alle Pakete aktualisiert hast?
Ich habe ja beides geändert, also update auf 4.4.30 und fast gleichzeitig das caching für die 404-Seite ausgeschaltet.
Ich nehme noch mal das caching für die 404 wieder rein bzw. die Ausnahme wieder raus, um zu prüfen, ob das System auch mit globalem Caching keine 404 cacht.
Morgen wissen wir dann mehr.
Viele Grüße,
conter
Scheint doch ein Problem zu geben:
Schon jetzt hat sich der Ordner http_cache wieder gefüllt.
Ich habe in den Logs folgende Fehlermeldungen:
Code:[2018-12-12 15:48:22] request.INFO: Matched route "contao_backend". {"route":"contao_backend","route_parameters":{"_scope":"backend","_token_check":true,"_controller":"Contao\\CoreBundle\\Controller\\BackendController::mainAction","_route":"contao_backend"},"request_uri":"https://www.###.de/contao?act=edit&do=article&id=3156&mode=2&pid=808&ref=SJeKwHC1&rt=3we3llgyWPQDE-njEAtTxEMRiA6R4tK8DRr21sKRMK8&table=tl_content","method":"POST"} []
[2018-12-12 15:48:22] security.INFO: Attempting SimplePreAuthentication. {"key":"backend","authenticator":"Contao\\CoreBundle\\Security\\ContaoAuthenticator"} []
[2018-12-12 15:48:22] app.CRITICAL: An exception occurred. {"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\AccessDeniedHttpException(code: 0): Cannot load record \"tl_content.id=3156\". at /home/###/public_html/v1/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php:106, Contao\\CoreBundle\\Exception\\AccessDeniedException(code: 0): Cannot load record \"tl_content.id=3156\". at /home/###/public_html/v1/vendor/contao/core-bundle/src/Resources/contao/drivers/DC_Table.php:1802)"} []
[2018-12-12 15:48:25] request.INFO: Matched route "contao_backend". {"route":"contao_backend","route_parameters":{"_scope":"backend","_token_check":true,"_controller":"Contao\\CoreBundle\\Controller\\BackendController::mainAction","_route":"contao_backend"},"request_uri":"https://www.###.de/contao?act=edit&do=article&id=3156&mode=2&pid=808&ref=SJeKwHC1&rt=3we3llgyWPQDE-njEAtTxEMRiA6R4tK8DRr21sKRMK8&table=tl_content","method":"HEAD"} []
[2018-12-12 15:48:26] security.INFO: Attempting SimplePreAuthentication. {"key":"backend","authenticator":"Contao\\CoreBundle\\Security\\ContaoAuthenticator"} []
[2018-12-12 15:48:26] request.INFO: Matched route "contao_backend". {"route":"contao_backend","route_parameters":{"_scope":"backend","_token_check":true,"_controller":"Contao\\CoreBundle\\Controller\\BackendController::mainAction","_route":"contao_backend"},"request_uri":"https://www.###.de/contao?act=edit&do=article&id=3156&mode=2&pid=808&ref=SJeKwHC1&rt=3we3llgyWPQDE-njEAtTxEMRiA6R4tK8DRr21sKRMK8&table=tl_content","method":"GET"} []
[2018-12-12 15:48:26] security.INFO: Attempting SimplePreAuthentication. {"key":"backend","authenticator":"Contao\\CoreBundle\\Security\\ContaoAuthenticator"} []
[2018-12-12 15:48:26] app.CRITICAL: An exception occurred. {"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\AccessDeniedHttpException(code: 0): Cannot load record \"tl_content.id=3156\". at /home/###/public_html/v1/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php:106, Contao\\CoreBundle\\Exception\\AccessDeniedException(code: 0): Cannot load record \"tl_content.id=3156\". at /home/###/public_html/v1/vendor/contao/core-bundle/src/Resources/contao/drivers/DC_Table.php:1802)"} []
Ah, daran liegt das also ... Ich treffe schon seit geraumer Zeit immer wieder auf das Problem. In Contao selbst lässt sich dann ja oft nicht einmal mehr die Seitenwartung öffnen. Lösche dann /var/cache/prod per FTP, was teilweise ordentlich lange braucht. Bei Seiten, die dieses Problem häufiger aufweisen, laufen Cron-Jobs, um /var/cache/prod regelmäßig zu löschen - aber selbst die scheitern, wenn der Zeitraum zu groß gewählt ist. Naja, jedenfalls gut zu wissen, woran das überhaupt liegt!
Den var/cache/prod Ordner solltest du niemals bei einer Live Seite während des Betriebs löschen.
Hallo,
ich habe ebenso das Problem das der Cache im Ordner 'en' extrem groß wird. Der Cache wurde erst nach einem Update von 3.5 auf 4.4 so groß.
Die Einstellung, dass 404 Seiten expliziet nicht gecached werden habe ich bereits vorgenommen und bei Stichproben konnte ich auch keine 404 Seiten mehr im Cache finden. Dennoch ist der Cache innerhalb von ca. 4 Tagen wieder auf 16 GB angewachsen. In den Startseiten der Seitenstruktur ist der Servercache jeweils mit 6 Stunden angegeben.
Kann mir jemand einen Tipp geben, was hier falsch läuft. Wir laufen Gefahr das sich MySQL verabschiedet, wenn der Diskspace beim Provider ausgeht. Klar könnte ich einen Cronjob zum Leeren des Caches anlegen, aber eigentlich soll doch Contao das machen?! Die Größe des Caches scheint mir auch nicht normal zu sein, oder irre ich da. Die Installation ist zwar 4sprachig und hat jede Menge Inhalt, aber mehrere GB Cache scheinen mir doch fehlerhaft, oder?
Vielen Dank für Eure Hilfe!!!
Contao Version 4.4.35
PHP Version 7.2
Hast du schon mal analysiert, welche Seiten sich da im Cache befinden? Also welche Seiten sich besonders oft im Cache befinden?
Am häufigsten sind Newsseiten vorhanden, was jedoch der Seite entspricht. Aber auch Events und normale Inhaltsseiten sind im Cache. Auch Seiten mit unterschiedlichen Base URLs, welche durch 301 Weiterleitungen generiert werden sind im Cache.
Eigentlich hätte ich angenommen, dass bei einer Einstellung von 6Stunden TTL in den Startpunkten nach 6 Stunden ca. ein Mittelwert der Cachegröße erreicht ist. Jetzt nach 5 Stunden seit dem letzten Leeren des Caches ist der Ordner 'http_cache' 768MB groß. Wie kann es da sein, dass nach 4 Tagen die Cachegröße bei 16GB liegt? Kann es sein, dass das Clearing des Caches aus irgendeinem Grund nicht richtig funktioniert?
Was genau meinst du damit?Zitat:
Zitat von dait
Sorry. Die 301 Weiterleitungen waren nicht korrekt, weshalb auch andere Base-Urls im Seitencache lagen. Das ist nun aber korrigiert.
Dennoch finde ich Dateien im Seitencache, welche deutlich älter als 6 Stunden sind. Einstellung des Servercaches ist wie gesagt auf 6 Stunden angegeben. Dann dürften doch eigentlich keine Dateien älter als 6 Stunden im Cache sein, oder?
Mit dem HTTP Reverse Proxy Cache kenne ich mich leider zu wenig aus. Du könntest deine Erfahrungen hier posten: https://github.com/contao/contao/issues/231
In Ordnung - Danke!
Würde diesen Thread gern nochmal hervor holen. Hier wurden ja einige Theorien geäußert, wie es zu diesen Cache Größen kommen kann.
Mein Eindruck ist schlicht der, dass der Seitencache seit Contao 4 nicht mehr von selbst bereinigt wird. Bei den 3er Versionen geschah das wöchentlich über den Contao eigenen Cron. Ich habe schlicht nicht den Eindruck dass es in Contao 4 so einen Job gibt.
Aus meiner Sicht müssten da draußen jedem der den serverseitigen Cache aktiviert hat das Cache Verzeichnis volllaufen, sofern es nicht ab und an manuell (Systemwartung) bereinigt wird.