adschm
commented
6 years ago Runtimes wenn Frisch gelöscht (keine Daten zu Löschen): --- Delete stats: 3.9459452629089355 seconds --- --- Delete neighbor-stats: 5.37498927116394 seconds --- --- Delete netif stats: 25.54477071762085 seconds --- --- Delete events: 0.06570601463317871 seconds --- --- Total duration: 34.93512797355652 seconds ---
Runtimes mit Daten von 12 Stunden: --- Delete stats: 5.213935613632202 seconds --- --- Delete neighbor-stats: 8.972987413406372 seconds --- --- Delete netif stats: 92.83474469184875 seconds --- --- Delete events: 0.02640223503112793 seconds --- --- Total duration: 107.28229260444641 seconds ---
Schlussfolgerungen:
- Mit warmem Cache (wie hier) ist mit ca. 4-5 Minuten Gesamtlaufzeit zu rechnen.
- Nach einem DB-Neustart ist die Zeitspanne wohl länger (aber es ist nicht klar, ob die Datenbank durchgehend gelockt ist)
- Kritischer Schritt ist die Tabelle router_stats_netif mit ca. 50 Mio. Einträgen
Ursache des Problems:
- Beim normalen Router-Einlesen werden die Interfaces erst gelöscht (DELETE) und dann wieder in die Tabellen geschrieben (INSERT INTO). UPDATE ist hier kompliziert, weil ja netifs dazukommen und wegfallen können.
- Ist jetzt die Datenbank gelockt, wenn die eigentlichen Routerdaten geschrieben werden oder beim DELETE-Befehl, dann fehlt einfach ein Datenpunkt und fertig. Tritt das Lock aber beim INSERT INTO auf, wird diese nicht ausgeführt, die alten Daten sind aber schon gelöscht. Entsprechend kann der Router bei der nächsten Anfrage mangels MAC-Adresse nicht zugeordnet werden und wird dupliziert.
Maßnahmen (umgesetzt):
- Commit nach jedem Einzelschritt in routertools/delete_old_stats
- Erhöhen der innodb_lock_wait_timeout von 50 (default) auf 240 Sekunden (<5 min!)
Weitere Ideen:
- Alfred-API abschalten, solange delete_old_stats läuft (manuelles lock-file) => Nachteil: Bei frischer DB sehr lange, also alle Router kurz offline (oder das updateskript mit abschalten)
- Auf DELETE/INSERT verzichten und Schleife über die Interfaces bauen, die dann je nach Fall UPDATE/INSERT/DELETE auslöst => Nachteil: Umständlich und pfui
- Verkürzung der Statistik auf 7 Tage => Löst Problem nicht wirklich
Ich habe nachts einen restart gemacht. und um 4:02 löscht die VM die alte statistik. die war nicht mehr im cache und dadurch musste der die komplette db von der hdd lesen. Das hat ca. 20 min gedauert und solange war die db gelockt, sodass nicht geschrieben werden konnte und manche Router dupliziert wurden (interessanterweise nur V2 und auch nur einzelne).
Exceptions wurden geloggt, aber die Router sollten sich nicht multiplizieren.
Sollte im Code abgefangen werden!