BackupDB müllt Server zu

[LutzWinkler]

In den letzten Tagen hatte ich mit einem massivem Problem zu tun, das letztendlich sogar meinen Server lahm gelegt hat.
Folgende Symptome:

• Es begann damit, dass im FE jegliches Layout verschwunden war
• Nach einigem Suchen muste ich feststellen, dass alle *.css Dateien im Typolight-Root leer waren (0 Bytes)
• Beim Versuch, per FTP Backups der Dateien hochzuladen, kam eine allgemeine Fehlermeldung
• Auch Editieren und neu abspeichern war nicht möglich - die Dateien blieben leer
• Kurze Zeit später war überhaupt kein Zugang auf die Site mehr möglich. Sowohl im FE als auch im BE erschien nur noch die Meldung, ich solle den Admin informieren, und in localconfig.php 'DisplayErrors' auf true setzen
• als dann auch noch die localconfig.php leer und nicht mehr zu editieren war kam langsam Panik auf
• Ich habe dann in einer Nachtsitzung mit Hilfe von Putty über meinen Root-Zugang mit wget Backups der geleerten Dateien aufspielen können
• Danach klappte der Zugang wieder eine Weile. Allerdings spürbar langsamer.
• Echte Verzweiflung kam dann auf, als auch die Bankenbank anfing zu spinnen: MySQL meldet: #1030 - Got error 28 from storage engine
• Wenig später begann das Problem wieder von vorne: das Layout ging flöten und die CSS-Dateien waren wieder leer
• Unnötig zu bemerken, dass mir natürlich auch der Provider nicht weiterhelfen konnte!

Nach tagelangen Recherchen habe ich jetzt endlich das Problem lokalisieren können:

• Die Home-Partition des Server war voll!!!
• Im TL-Verzeichnis /system/tmp waren über 1000 Dateien (z.B. 97f30c2f57005202ec9b4f2c1c4151ea) mit einer Länge von 10.910.704 Bytes
• Nach dem Löschen dieser Dateien (Systemwartung->Daten bereinigen) ließen sich die Backups aufspielen und der Zugang funktionierte wieder
• Allerdings wurde jede Minute in /system/tmp wieder eine neue Datei angelegt!!!
• Die Dateien waren unvollständige SQL-Dumps meiner Datenbank (endeten meist irgendwo bei tl_member)
• Obwohl BackupDB jede Nacht um 2 Uhr laufen sollte, war laut Scheduler die letzte Ausführung am 25.03.2010 08:11
• Bei meinen Recherchen im Forum bin ich auf das Problem mit den Skriptlaufzeiten gestossen. Aber selbst eine Erhöhung der max_execution_time auf 180 Sekunden brachte (nach Reboot des Servers) keine Änderung

Hier einige Systeminfos:

• Auf dem Server läuft openSUSE 10.3
• Typolight Version 2.8.1
• Cron 1.0.0 stable Build 15
• Cornjobs werden vom Server getriggert
• BackupDB 1.1.3 stable Bulid 10
• AutoBackupDB.php vom 29.03.2009, // $this->User->authenticate(); ist auskommentiert
• Manuelle Sicherung der Datenbank mit BackupDB im BE dauert 5 Sekunden. Die Datei ist 10.913.885 Bytes (10,4 MB) groß!
• Seit ich DBBackup im Scheduler deaktiviert habe, gibt's keine Probleme mehr

Ihr könnt euch sicher vorstellen, dass ich ziemlich angefressen bin!!!

Da ich nun weiß Gott kein Unix-Guru bin, habe ich natürlich ewig gebraucht, das Problem zu lokalisieren.
Wenn ich keinen Root-Zugriff auf den Server gehabt hätte, hätte ich meine TL-Installation einstampfen können.
Ich stand schon kurz davor, den Provider zu wechseln - und hätte wahrscheinlich nach einiger Zeit genau die selben Probleme gehabt.

Abschließend ein paar Fragen an die TL-Entwickler (deren Arbeit ich übrigens sehr schätze):

• Wie kann es sein, dass über 1000 temporäre Dateien anfallen, ohne dass das System den Vorgang abbricht?
• Ich glaube nicht, dass die Probleme mit den Skriptlaufzeiten oder Benutzerrechten zusammenhängen, wie immer wieder im Forum behauptet
• Wie ausgereift sind Cron und BackupDB?

Gruß, Lutz

[MacKP]

Hallo LutzWinkler,
du könntest BackupDBplus nehmen -> https://contao.org/erweiterungsliste...000029.de.html

Da kannst du dann ausnahmen definieren und so die größe von dem Backup eingrenzen.
Zum Beispiel den Suchindex raus nehmen. Das spart in der Regel ziemlich viel.
Oder du Teilst das Backup ein (verschiedene Tabellen erst nacheinander, wenn du davon ausgehen kannst, das zu der Zeit eh nicht daran gearbeitet wird).

Dadurch solltest du dann nicht mehr so schnell in solche Problemzonen kommen.

Viele Grüße

[do_while]

Hallo LutzWinkler,

das tut mir natürlich sehr leid, was Dir da passiert ist.
Offenbar ist das Backup größer, als es der cron-Start schafft zu sichern. Ich nehme mal an, dass Du den SaveMode Hack verwendest, da sonst die Datei direkt im Zielverzeichnis tl_files/AutoBackupDb erstellt werden würde.
Das Problem ist jetzt, dass die Datei vorerst unter system/tmp aufgebaut wird und dann per FTP an den Zielort gespielt wird. Danach wird die temporäre Datei gelöscht. Wenn jetzt das Backup abbricht, bleibt die Datei in system/tmp übrig, ohne dass jemand weis, dass sie da ist und wie sie heißt.
Dieses Handling übernimmt komplett die File-Klasse aus der TL-Library.

Wie MacKP schon geschrieben hat, kannst Du mit BackupDBPlus das Backup in einzelne Teile aufsplitten oder auch Tabellen weglassen, die sich wieder generieren lassen, wie der Suchindex. Die Größe der Sicherung sollte sich damit wesentlich reduzieren lassen.

[LutzWinkler]

Danke für die Hinweise!

Was ich nicht verstehe:
das manuelle Backup dauert gerade mal 10 Sekunden und mit 10MB ist die Sicherungsdatei auch nicht wirklich groß.
Warum sollte es da ein Problem mit der Skript-Execution-Time geben???

[do_while]

Das verstehe ich auch nicht so ganz, vielleicht läuft es getrigger über einen echten Cronjob mit niedrigerer Priorität?

Unterschied ist aber auch, dass beim manuellen Backup die Datei per Download kommt, d.h. sie wird nicht im Dateisystem abgelegt. Offenbar liegt hier irgendwo das Problem.

[LutzWinkler]

Nachtrag:
Nachdem ich auf BackupDBplus umgestiegen bin ist der Server jetzt 2 Wochen stabil gelaufen.
Gestern hatte ich wieder einen Komplettausfall: diesmal war das Root-Laufwerk / voll!

Nach einigem Suchen habe ich eine fast 2GB große Log-Datei von Apache gefunden:
/var/log/apache2/gynamed/gynamed-access_log

Die habe ich natürlich nicht herunterladen oder ansehen können.
Nach dem Löschen sind relativ schnell alle möglichen Eintragungen mit 'cron.php' aufgelaufen.

Erst jetzt habe ich bemerkt, dass ich in der fe_page.tpl noch einen Trigger für den Pseudo-Cronjob hatte. Da ich ja schon länger einen serverseitigen Cronjob nutze, habe ich das jetzt gelöscht.

Bin mal gespannt, ob das das Problem behoben hat!

[FloB]

Das ist die Standard-Protokolldatei des Apache Servers. Du solltest dir einen Logrotator anschauen. Welche Distribution nutzt du?

Edit: Du solltest auch mal schauen, was für große Dateien du auf dem Dateisystem hast (aber bitte nicht blind löschen!):

`find / -size +10000k`

Dieser Code findet alle Dateien, die größer als 10Mb sind (mehr Befehle gibt es hier).

[LutzWinkler]

Zwischenzeitlich ist der Server einigermaßen stabil gelaufen. Das Müllproblem scheint behoben zu sein.

Jetzt wird allerdings der Seitenaufbau immer langsamer - obwohl ich an der Funktionalität (Foren, Download etc.) nicht viel geändert habe.

Da sich auch der Traffic in Grenzen hält, fürchte ich, dass es wieder irgendwie mit dem Scheduler zu tun hat.

Folgende Jobs arbeitet der Scheduler ab:
alle 5 Minuten: /system/modules/helpdesk/HelpdeskNotify.php
jede Nacht um 2 Uhr: system/modules/BackupDBplus/AutoBackupDB.php

Auf dem Server steht in /etc/crontab:

* * * * * root wget -t 1 -O - http://www.gynamed.telemed.de/system...Controller.php >& /dev/null

Außerdem fällt auf, dass der Seitenaufbau nur im Front- und Backend von TL verlangsamt ist. Beim Zugriff per FTP oder phpMyAdmin ist keine Verlangsamung spürbar.

Ein ähnlich konfigurierte TL-Site bei Goneo läuft auch wesentlich zügiger.

Die Seite ist hier zu besichtigen: gynamed.net

Da ich kein Linux-Insider bin, wüsste ich zu gerne, wie ich herausfinden kann, was den Seitenaufbau so ausbremst!

[do_while]

Hallo,

erstmal ist auf der Homepage kein Grund zu erkennen. Nichtmal der Core-Cron wird hier aufgerufen (ob das gut ist, sei dahin gestellt). Da die Cron-Erweiterung standardmäßig nur im Backend getriggert wird, oder wie hier, mittels Cronjob, kann daraus eigentlich auch keine Belastung im Frontendaufruf entstehen.

Es kann allerdings sein, dass das Fehlen des cron.php-Aufrufs aus dem Standard-Template fe_page.tpl einen gewissen Datenstau verursacht, weil das tägliche und wöchtenliche Aufräumen und Bereinigen einfach fehlt.

Wie sehen denn die Inhalte der Datenbanktabelen aus?
Ist hier eine Tabelle mit übermäßig vielen Datensätzen erkennbar?

[LutzWinkler]

Ich habe mal die größten Tabellen mit phpMyAdmin rausgesucht:

tl_session:
Größe 223,7 MB; Überhang 129,8 MB; 9 Einträge

tl_log:
Größe 14,0 MB; 66591 Einträge

tl_member:
912,9 KB; 1992 Einträge

tl_search_index:
399,4 KB; 6177 Einträge

tl_helpdesk_ticketmarks:
302,5 KB; 4222 Einträge

tl_helpdesk_categorymarks:
139,1 KB; 2345 Einträge

tl_repository_instfiles:
100,7 KB; 1064 Einträge

Keine Ahnung, warum die tl_session so groß ist!??

[do_while]

Na, wie ich schon vermutet habe, fehlt da der normale Cron (aus dem Core) der da reglemäßig etwas aufräumt und die Vorhaltezeiten der Einträge aus den Einstellungen überwacht.

Ich glaube aber nicht, dass das im normalen Betrieb auf die Gesamtperformance geht.

[LutzWinkler]

Wie kann ich den aufrufen - und kann ich den Inhalt der tl_session einfach löschen (wenn grade keine online ist)???

[MacKP]

Hallo LutzWinkler,
schau doch mal in die Systemwartung.
Da solltest du fündig werden ;-)

Viele Grüße

[LutzWinkler]

Dank für den Hinweis MacKP!

Ich nehme an, du meinst den Punkt "Daten bereinigen"?

Das habe ich schon öfters gemacht - ein spürbaren Geschwindigkeitsgewinn hat das nicht wirklich gebracht!

tl_session ist immer noch 223 MB groß und tl_log hat 67111 Einträge.

[do_while]

Hallo LutzWinkler,

die Sessiondaten enthalten die Sessions aller Nutzer, wahrscheinlich auch alte Sessions. Deine eigene Session kannst Du in den Benutzereinstellungen löschen.

Du könntest aber auch probieren, den Core-Cron in Deinem Template kurz vor dem Ende nachzurüsten:

     :
<!-- indexer::stop -->
<img src="<?php echo $this->base; ?>cron.php" alt="" class="invisible" />
<!-- indexer::continue -->

</div>
</body>
</html>

[LutzWinkler]

Gestern Abend zwischen 21:10 und 23:17 ist meine tl_session auf über 363677 Einträge angewachsen. Fast alle Datensätze hatten meine IP-Adresse - obwohl ich die Seite in dieser Zeit überhaupt nicht aufgerufen hatte!
Normalerweise ist die Seite in dieser Zeit auch nicht sehr stark frequentiert.

Ich habe jetzt die tl_session mal beherzt mit phpMyAdmin geleert, und siehe da:
jetzt läuft alles wieder wie geschmiert!!!

Da mit immer noch nicht klar ist, was die Ursache für dieses Verhalten ist, bin ich mir nicht sicher, ob ich den letzten Tipp von do_while befolgen soll.

Außerdem ist mir noch nicht ganz klar, wo genau in den Benutzereinstellungen ich meine eigenen Sessions löschen kann.

[joerg-t]

Außerdem ist mir noch nicht ganz klar, wo genau in den Benutzereinstellungen ich meine eigenen Sessions löschen kann.

Im BE oben links neben dem Link Frontend-Vorschau steht Benutzer LutzWinkler da einfach mal einen Klick auf den LutzWinkler angemeldeten Benutzer machen.

[do_while]

Hallo LutzWinkler,

wenn Deine Sessiondaten gespeicherten sprunghaft ansteigen, obwohl Du in diesem Zeitraum nicht aktiv bist, solltest Du mal die Server-Logs studieren, um herauszufinden, was um diese Zeit wirklich gelaufen ist. Eigentlich haben nur Mitglieder und Benutzer Sessiondaten in der Datenbank, wenn also keiner eingeloggt ist, sollte sich da auch nichts verändern oder vergrößern.

[LutzWinkler]

Die Apache Log-Datei würde ich ja gerne lesen, nur: sie ist auf 1.2 GB angewachsen!!!
Und zwar innerhalb von 11 Tagen um 750 MB.

Ich weiß nicht, wie ich diese Dateien auf der Linux-Console vernünftig analysieren soll.

Jedenfalls wieder das alte Problem: der Server müllt zu!

[FloB]

Du brauchst logrotate o. ä., und wenn du das nicht installieren kannst, kannst du in der Apache-Config variable Dateinamen (täglich wechseln ist immer gut) für die Logs angeben, siehe Manual.