Hallo,
ab sofort steht LiveConfig 3.1.4 zum Download in den Repositories bereit.
Dieses Update behebt einen lästigen Effekt, der sich erst mit v3.0.5 bemerkbar gemacht hat und nur Systeme betraf, die auch eine größere Anzahl an Postfächern (> mehrere Hundert) hosten.
Technische Details (nur für Interessierte):
Verschiedene Kunden meldeten uns seit den letzten Versionen immer wieder mal merkwürdige "Hänger" in LiveConfig - nicht eindeutig lokalisierbar, und nach einiger Zeit wieder von alleine verschwunden. Im Log fand sich zudem auch nichts.
Es war leider alles andere als einfach, dieses Verhalten zu reproduzieren. Letztendlich stellten wir in einer intensiven Debugging-Session mit einem akut betroffenen Kunden fest, dass diese Verzögerungen/Blockaden von Datenbankzugriffen verursacht wurden, und zwar auf den RRD_MAIL-Datensätzen. In dieser Zeitserien-Tabelle speichert LiveConfig den E-Mail-I/O - eigentlich recht unspektakulär, und auch nur für 24 Stunden bzw. 31 Tage. An dem Code haben wir seit Jahren nichts geändert (der wurde von LiveConfig v2 übernommen). Was sich aber geändert hat ist, dass die verwendete Tabelle inzwischen eine sogenannte "Foreign Key Constraint" enthält. Diese sorgt dafür, dass bei Löschen eines Postfachs aus der Datenbank die zugehörigen RRD-Daten automatisch (ohne eine Zeile Code) mit gelöscht werden. Soweit auch alles normal. Wie wir aber herausgefunden haben, dauert das Einfügen in eine Tabelle mit Foreign-Key-Constraint nun bis zu 2ms länger als vorher (weil die Datenbank die entsprechenden Fremdschlüssel gleich prüft).
Trifft nun für ein Postfach erst nach längerer Zeit erneut eine E-Mail ein, gibt es eine "Lücke" in den Statistiken, welche der RRD-Code bislang mit Null-Werten aufgefüllt hat. Mussten z.B. 1000 Intervalle mit Nullen aufgefüllt werden, so dauerte das plötzlich 1000 x 2ms = 2 Sekunden - statt insgesamt 2-3ms vorher. Nun purzeln die Statistiken nicht einzeln pro Postfach herein, sondern kommen alle 5 Minuten im Batch. Somit waren alle Datenbank-Threads komplett mit dem Einfügen von Null-Daten beschäftigt.
Interessanterweise betrifft dieses Verhalten sowohl SQLite als auch MySQL. Betroffen waren aber "nur" Systeme ab einer bestimmten Anzahl an Postfächern und einem bestimmten Auftreten von Statistikdaten (eben mit häufigen "großen Lücken").
Mit v3.1.4 haben wir den RRD-Code überarbeitet - es werden nun keine Null-Werte mehr in der Datenbank aufgefüllt, das erfolgt nun (je nach Abfragefall) während der Ausgabe der Daten, und auch da stark optimiert.
Dieser Fehler ist (leider) ein typisches Beispiel für sogenannte "problems at scale" - Probleme, die erst in einer gewissen Größenordnung auffallen.
An dieser Stelle möchten wir uns herzlich für die Unterstützung beim Debugging bedanken!
Viele Grüße
-Klaus Keppler