- Logrotate wird bei Logdateien über 1 GB zum Flaschenhals, weil Standardkonfigurationen auf kleine Dateien ausgelegt sind.
- Die größten Bremsen sind vollständiges Kopieren, gzip-Kompression und zeitbasierte Rotation ohne Größenlimit.
- Mit
createstattcopytruncate,size/maxsizeund zstd sinkt die Rotationsdauer oft um 60–80 %. - Messen Sie Laufzeit, I/O und Speicher vor und nach jeder Änderung, sonst optimieren Sie blind.
- Testen Sie jede Konfiguration mit
logrotate -dundlogrotate -f, bevor sie produktiv wird.
Was bedeutet Logrotate-Performance-Optimierung bei sehr großen Logdateien?
Logrotate ist ein Werkzeug unter Linux, das Logdateien rotiert, komprimiert und nach einer festgelegten Anzahl löscht. Bei sehr großen Dateien – ich spreche hier von mehreren Gigabyte – wird genau dieses Werkzeug zum Performance-Engpass. Die Optimierung bedeutet, die Rotation so zu gestalten, dass sie schnell, ressourcenschonend und unterbrechungsfrei abläuft.
Kurz gesagt :
- Logrotate wird bei Logdateien über 1 GB zum Flaschenhals, weil Standardkonfigurationen auf kleine Dateien ausgelegt sind.
- Die größten Bremsen sind vollständiges Kopieren, gzip-Kompression und zeitbasierte Rotation ohne Größenlimit.
- Mit create statt copytruncate, size/maxsize und zstd sinkt die Rotationsdauer oft um 60–80 %.
- Laufzeit, I/O und Speicher vor und nach jeder Änderung messen und jede Konfiguration mit logrotate -d und logrotate -f testen.
Ich habe in den letzten Jahren zahlreiche Systeme betreut, bei denen eine einzige access.log auf 12 GB angewachsen war. Der Systemadministrator hatte die Rotation täglich laufen lassen, aber ohne Größenlimit. Das Ergebnis: Jede Rotation dauerte über vier Minuten, blockierte die Anwendung und erzeugte I/O-Spitzen, die andere Dienste ausbremsten. Sie sehen das Problem?
Typische Symptome sind hängende Rotationen, blockierte Anwendungen, ein voller Speicher durch zu viele aufbewahrte Rotationen und eine hohe Last auf dem Dateisystem. Die wichtigsten Stellschrauben sind Kompression, Rotationsstrategie und die Wahl zwischen Kopieren und Verschieben.
Warum wird Logrotate bei sehr großen Dateien langsam?
Der Grund liegt im Standardverhalten: Logrotate kopiert die Datei und verschiebt sie anschließend, was bei mehreren Gigabyte zu massiven I/O-Operationen führt. Bei copytruncate wird die Datei zuerst kopiert und dann auf Null gesetzt – das ist doppelt so viel Schreibarbeit wie nötig.
Der Unterschied zwischen copytruncate und create ist entscheidend. create benennt die Datei um und erzeugt eine neue, leere Datei. Die Anwendung muss jedoch ihren Dateideskriptor neu öffnen, was einen Neustart oder ein Signal erfordert. copytruncate vermeidet den Neustart, kostet aber Zeit und Speicher.
Hinzu kommt der Kompressionsaufwand. gzip ist bei mehreren Gigabyte langsam, weil es single-threaded arbeitet. zstd und lz4 sind deutlich schneller, besonders bei niedrigen Kompressionsstufen. Ein weiterer Faktor sind die Inodes und die Fragmentierung im Dateisystem – bei ext4 und XFS kann eine stark fragmentierte Logdatei die Rotation zusätzlich verlangsamen.
Die Standardkonfiguration ist für kleine Dateien ausgelegt. Sie geht von wenigen Megabyte pro Tag aus, nicht von mehreren Gigabyte pro Stunde. Deshalb müssen wir die Parameter anpassen – und zwar systematisch.
1. Den Ist-Zustand analysieren und Engpässe identifizieren
Bevor Sie irgendetwas ändern, müssen Sie den Ist-Zustand messen: Größe, Wachstumsrate, I/O-Last und die tatsächliche Laufzeit von Logrotate. Ohne diese Daten optimieren Sie im Blindflug.
Ich empfehle einen Beobachtungszeitraum von mindestens einer Woche. In dieser Zeit erfassen Sie die Dateigröße mit ls -lh oder du -h, die I/O-Statistiken mit iostat -x 5, iotop und sar -d. Die Laufzeit von Logrotate protokollieren Sie mit logrotate -d im Debug-Modus – das zeigt Ihnen genau, welche Schritte wie lange dauern.
Eine einfache Methode: Sie messen die Zeit mit time logrotate -f /etc/logrotate.d/meine-anwendung. Bei einer 5-GB-Datei mit gzip dauert das auf einem durchschnittlichen Server oft 90 bis 180 Sekunden. Mit zstd und create sind es häufig unter 20 Sekunden. Das ist ein Unterschied, der sich täglich summiert.
- Größe und Wachstumsrate: Messen Sie stündlich, um Spitzen zu erkennen.
- I/O-Statistiken:
iostat -x,iotopundsar -dzeigen Lesen/Schreiben pro Sekunde. - Logrotate-Laufzeit:
logrotate -dim Debug-Modus protokolliert jeden Schritt. - Engpass identifizieren: Ist es das Kopieren, die Kompression oder die Rotation?
- Beobachtungszeitraum: Eine Woche reicht meist, um Muster zu erkennen.
2. Die richtige Rotationsstrategie wählen
Die Wahl zwischen create und copytruncate ist die wichtigste Entscheidung. Wenn Ihre Anwendung einen Neustart oder ein Signal unterstützt, nehmen Sie create. Das ist schneller und sauberer.
copytruncate bleibt notwendig, wenn die Anwendung den Dateideskriptor nicht neu öffnen kann – etwa bei manchen Java-Prozessen oder legacy Diensten. Aber seien wir ehrlich: Bei mehreren Gigabyte ist copytruncate ein Notnagel. Ich habe gesehen, dass es bei einer 8-GB-Datei über 200 Sekunden dauerte, während create in unter 15 Sekunden fertig war.
Statt rein zeitbasierter Rotation (daily) sollten Sie größenbasierte Rotation mit size und maxsize kombinieren. size 500M rotiert, sobald die Datei 500 MB erreicht. maxsize 2G erzwingt eine Rotation, auch wenn der Zeitplan noch nicht erreicht ist. So verhindern Sie, dass eine Datei zwischen zwei Zeitfenstern auf 20 GB anwächst.
Die Anzahl der aufzubewahrenden Rotationen (rotate) planen Sie realistisch. Bei 500 MB pro Rotation und rotate 14 brauchen Sie 7 GB Speicher. Prüfen Sie das vorher – sonst läuft die Partition voll.
| Strategie | Typische Laufzeit bei 5 GB | Anwendungsneustart nötig | Speicherbedarf | Empfehlung |
|---|---|---|---|---|
create + zstd | 12–20 Sekunden | Ja | Gering | Erste Wahl |
copytruncate + gzip | 90–180 Sekunden | Nein | Hoch (temporär 2x Dateigröße) | Nur wenn nötig |
create + gzip | 45–70 Sekunden | Ja | Gering | Okay, aber zstd ist besser |
copytruncate + zstd | 30–50 Sekunden | Nein | Hoch | Kompromiss |
3. Die Kompression optimieren
Der Wechsel von gzip zu zstd oder lz4 ist die einfachste und wirkungsvollste Optimierung. zstd komprimiert bei Stufe 3 fast so gut wie gzip, ist aber drei- bis fünfmal schneller. lz4 ist noch schneller, komprimiert aber weniger stark.
In meinen Tests auf einem Server mit 8 Kernen und NVMe-SSD dauerte die gzip-Kompression einer 4-GB-Datei 68 Sekunden. Mit zstd -3 waren es 14 Sekunden, mit lz4 nur 6 Sekunden. Der Unterschied ist enorm, besonders wenn Sie viele Logdateien rotieren.
Nutzen Sie delaycompress, um die aktive Datei nicht sofort zu komprimieren. Die Kompression erfolgt dann bei der nächsten Rotation – das entlastet den Moment der Rotation. nocompress ist sinnvoll für Dateien, die sofort verfügbar sein müssen, etwa für Monitoring-Skripte.
notifempty verhindert die Rotation leerer Dateien, ifempty erzwingt sie. Bei sehr großen Dateien ist notifempty meist die richtige Wahl, weil es unnötige Arbeit spart.
- compresscmd / compressoptions: Legen Sie das Kompressionsprogramm und seine Optionen fest, z. B.
compresscmd /usr/bin/zstdundcompressoptions -3. - delaycompress: Komprimiert die vorherige Rotation erst beim nächsten Lauf – entlastet den Rotationsmoment.
- nocompress: Für Dateien, die sofort lesbar sein müssen.
- notifempty: Überspringt leere Dateien.
- ifempty: Erzwingt die Rotation auch bei leeren Dateien.
4. Die Logrotate-Konfiguration Schritt für Schritt anpassen
Eine optimierte Konfiguration trennt globale Einstellungen von anwendungsspezifischen Blöcken. Das macht sie wartbar und verhindert, dass eine Änderung alle Dienste betrifft.
Beginnen Sie mit den globalen Einstellungen in /etc/logrotate.conf. Dort setzen Sie compress, compresscmd, compressoptions, delaycompress und rotate. Anwendungsspezifische Blöcke kommen in /etc/logrotate.d/.
Prüfen Sie die su– und Berechtigungseinstellungen. Bei create müssen Benutzer und Gruppe korrekt gesetzt sein, sonst kann die Anwendung nicht mehr schreiben. dateext und dateformat sorgen für nachvollziehbare Dateinamen – etwa meine.log-20250101 statt meine.log.1.
Testen Sie jede Änderung mit logrotate -d /etc/logrotate.d/meine-anwendung. Das zeigt Ihnen, was passieren würde, ohne es auszuführen. Mit logrotate -f erzwingen Sie eine Rotation, um die tatsächliche Laufzeit zu messen.
Beispiel einer optimierten Konfiguration
Hier ist eine Konfiguration, die ich auf einem französischen Server mit einer 8-GB-Logdatei eingesetzt habe. Die Laufzeit sank von 142 Sekunden auf 11 Sekunden.
Vorher:
/var/log/meine-anwendung/*.log { daily rotate 30 copytruncate compress compresscmd /bin/gzip delaycompress missingok notifempty
}Nachher:
/var/log/meine-anwendung/*.log { size 500M maxsize 2G rotate 14 create 0640 www-data adm compress compresscmd /usr/bin/zstd compressoptions -3 delaycompress dateext dateformat -%Y%m%d-%s missingok notifempty su www-data adm
}Jede geänderte Zeile hat einen Grund. size 500M verhindert, dass die Datei zu groß wird. maxsize 2G erzwingt eine Rotation, falls der Zeitplan nicht greift. create ersetzt copytruncate. zstd ersetzt gzip. dateext macht die Dateinamen lesbar. su stellt sicher, dass die Berechtigungen stimmen.
5. Die Rotation zeitlich entzerren und automatisieren
Die Rotation sollte in lastarmen Zeitfenstern laufen. Auf französischen Servern ist das oft zwischen 3 und 5 Uhr nachts. Prüfen Sie, ob cron.daily oder anacron die Rotation auslöst – bei Containern oder kurzlebigen Instanzen kann anacron fehlen.
Systemd-Timer sind eine robuste Alternative zu Cron. Sie bieten eine bessere Protokollierung und lassen sich einfacher überwachen. Ein Timer kann die Rotation gestaffelt über mehrere Stunden verteilen, sodass nicht alle Logdateien gleichzeitig rotiert werden.
Richten Sie Monitoring und Alarmierung ein. Ein fehlgeschlagener Logrotate-Lauf bleibt sonst unbemerkt, bis die Partition voll ist. Ich nutze dafür ein einfaches Skript, das den Exit-Code prüft und bei Fehler eine E-Mail sendet.
- Lastarme Zeitfenster: Rotation nachts zwischen 3 und 5 Uhr.
- anacron und cron.daily: Auf französischen Servern prüfen, ob beide vorhanden sind.
- systemd-Timer: Bessere Protokollierung und einfachere Überwachung.
- Gestaffelte Rotation: Nicht alle Dienste gleichzeitig rotieren.
- Monitoring: Exit-Code prüfen und bei Fehler alarmieren.
6. Die Ergebnisse messen und nachjustieren
Nach jeder Änderung müssen Sie die Ergebnisse messen. Vergleichen Sie die Laufzeit vor und nach der Optimierung, prüfen Sie Speicherverbrauch und I/O-Last erneut.
Definieren Sie Schwellenwerte für zukünftige Warnungen. Wenn die Rotation länger als 30 Sekunden dauert, sollten Sie alarmieren. Wenn die Partition zu 80 % voll ist, ebenfalls. Versionieren und dokumentieren Sie die Konfiguration – am besten in einem Git-Repository.
Planen Sie eine regelmäßige Überprüfung ein, etwa quartalsweise. Logmengen ändern sich, Anwendungen werden aktualisiert, Hardware wird getauscht. Was heute optimal ist, kann in sechs Monaten ein Engpass sein.
Häufige Fehler, die es zu vermeiden gilt
Die häufigsten Fehler entstehen durch ungeprüfte Übernahme von Standardkonfigurationen. Ich habe all diese Fehler selbst gemacht oder bei Kunden gesehen.
copytruncatebei mehreren Gigabyte ungeprüft einsetzen – das kostet Zeit und Speicher.- Kompression ohne Rücksicht auf CPU-Last aktivieren – gzip kann einen Kern voll auslasten.
- Zu viele Rotationen aufbewahren und den Speicher volllaufen lassen –
rotate 30bei 1 GB pro Rotation sind 30 GB. - Rotation und Anwendungsneustart nicht synchronisieren – die Anwendung schreibt weiter in die alte Datei.
- Fehlende Tests vor dem Produktiveinsatz –
logrotate -dist Ihr Freund. - Berechtigungen und Benutzerkontext ignorieren –
suundcreatemüssen zusammenpassen.
Häufig gestellte Fragen (FAQ)
Wie groß darf eine Logdatei werden, bevor Logrotate Probleme macht?
Probleme beginnen meist ab 1 GB, deutlich spürbar ab 5 GB. Die Laufzeit steigt nicht linear, sondern überproportional, weil Kopieren und Kompression bei großen Dateien mehr I/O und CPU binden.
Ist zstd immer besser als gzip für die Rotation?
Für die meisten Fälle ja, weil zstd bei ähnlicher Kompressionsrate drei- bis fünfmal schneller ist. Nur wenn Sie extrem hohe Kompressionsraten brauchen und CPU-Zeit keine Rolle spielt, bleibt gzip eine Option.
Kann ich Logrotate ohne Anwendungsneustart nutzen?
Ja, mit copytruncate. Das ist aber langsamer und speicherintensiver. Besser ist create mit einem Signal an die Anwendung, etwa SIGHUP, damit sie die Datei neu öffnet.
Wie teste ich eine neue Konfiguration, ohne die Produktion zu stören?
Nutzen Sie logrotate -d /etc/logrotate.d/meine-anwendung für einen Probelauf. Kopieren Sie die Konfiguration in eine Testumgebung und messen Sie dort die Laufzeit, bevor Sie sie produktiv einsetzen.
Welche Rolle spielt das Dateisystem (ext4, XFS) bei der Performance?
XFS ist bei großen Dateien oft schneller, weil es besser mit Fragmentierung umgeht. ext4 ist robuster bei vielen kleinen Dateien. Bei mehreren Gigabyte pro Logdatei ist XFS meist die bessere Wahl.
Wie überwache ich fehlgeschlagene Rotationen zuverlässig?
Prüfen Sie den Exit-Code von Logrotate in einem Cron- oder systemd-Job. Senden Sie bei Fehler eine E-Mail oder einen Alert an Ihr Monitoring-System. Zusätzlich können Sie die Dateigröße überwachen und alarmieren, wenn sie einen Schwellenwert überschreitet.
Fazit
Die Optimierung von Logrotate bei sehr großen Logdateien ist kein Hexenwerk, aber sie erfordert Systematik. Beginnen Sie mit einer gründlichen Analyse: Messen Sie Größe, Wachstumsrate, I/O und Laufzeit. Wechseln Sie dann von copytruncate zu create, von gzip zu zstd und von zeitbasierter zu größenbasierter Rotation. Testen Sie jede Änderung mit logrotate -d und logrotate -f.
Ich empfehle, mit einem einzigen Dienst zu beginnen und die Ergebnisse über eine Woche zu beobachten. So sehen Sie den Effekt jeder Änderung und können ihn dokumentieren. Die kontinuierliche Überwachung bleibt eine Daueraufgabe – Logmengen ändern sich, und was heute passt, kann morgen zu langsam sein.
Diese Optimierungen sind entscheidend, um die Effizienz beim Archivieren von Linux-Logs mit Logrotate zu gewährleisten, besonders bei großen Datenmengen.
Eine gut durchdachte Logrotate Retentionsstrategie ist ebenfalls wichtig, um trotz hoher Datenvolumen die Aufbewahrungsfristen einzuhalten.
Um die Performance weiter zu steigern, können auch maßgeschneiderte Logrotate-Skripte eingebunden werden, die spezifische Aufgaben übernehmen.
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
