openWB Forum

Jetzt habe ich den RC1 gut 24h laufen lassen. Das Gute ist, daß ich von 2 potentiellen Chromium-Prozessen nicht den ausmachen kann, der bisher problematisch war. Der eine verursacht eine etwas höhere CPU-Last als der andere: Diesen habe ich mitgeschrieben: Der andere hat höheren Speicherverbrauch, aber geringe CPU-Last (liegt bisher bei 9% CPU, 12% MEM): In jedem Fall scheint das Entfernen des Logging funktioniert zu haben.

Ich habe jetzt den Renderer-Prozess (1174) in der Überwachung. Ich werde in einigen Tagen sagen, wie sein Ressourcenverbrauch sich verhält.

Jetzt habe ich ab dem 13.11. 18:00 Uhr den Renderer-Prozess ein paar Tage gemessen. Dieser führt momentan die Prozess-Statistik an. Zur Erinnerung die Kommandozeile: Das Gesamtverhalten ist durch Entfernen des Loggings erheblich besser geworden. Der Speicherverbrauch schwankt etwas - es ist zu früh zu sagen, ob eine Tendenz nach oben vorliegt. Der Cpu-Verbrauch dagegen steigt nahezu linear an mit etwa 0,5% pro Tag. Somit sollte eine uptime von über 100 Tagen problemlos möglich sein. Ob das noch zu verbessern ist, kann ich mangels Erfahrung mit Webbrowsern nicht sagen.

Das sieht doch gar nicht so verkehrt aus. Ich baue noch eine Funktion ein, welche in der Nacht die Browser-Konsole leert. Vielleicht können wir da zumindest noch etwas Speicher frei bekommen. Für die ansteigende CPU-Last fehlt mir eine Stelle, wo ich das anpacken könnte.

Was spricht gegen einen automatischen Restart des chromium Prozesses z.B. täglich um 0:00?

Der Speicherverbrauch und die CPU-Nutzung gingen weiter hoch, letztere sogar etwas schneller. Jetzt begann das Fahrzeug nach Anstecken allerdings nicht zu laden, daher ein Neustart. Edit: PS - Stecker steckte nicht ganz, so daß die Verriegelung nicht griff und das Laden nicht begann.

Heute Nacht hat siech mein System mit der 2.1.6-Patch1 (Release) weggehängt - weder Display, noch Ping, ssh oder das Webinterface funktionierten noch. Nur Stromwegnahme half noch.

Hier das bis dahin mit 2.1.6-P1 ermittelte Lastdiagramm des Chromium-Render-Prozesses:
Die CPU-Last scheint leicht exponentiell zu steigen, während der Speicherverbrauch wie bekannt ansteigt. Interessant ist, daß die CPU-Last absank, nachdem ich dauerhaft die Energieflußanzeige auf dem Wallbox-Display aktiviert hatte (Am 24.12.)

Vom Speicher her würde ich sagen, daß nach 6 Wochen aus meiner Sicht Handlungsbedarf entsteht (voraussichtlich 70%)

zut hat geschrieben: Fr Dez 27, 2024 1:01 pm
Die CPU-Last scheint leicht exponentiell zu steigen, während der Speicherverbrauch wie bekannt ansteigt. Interessant ist, daß die CPU-Last absank, nachdem ich dauerhaft die Energieflußanzeige auf dem Wallbox-Display aktiviert hatte (Am 24.12.)

Vom Speicher her würde ich sagen, daß nach 6 Wochen aus meiner Sicht Handlungsbedarf entsteht (voraussichtlich 70%)

Die Balkendiagramme auf der Statusseite sind m.w. selbst geschrieben und nutzen keine fertige Lib wie chart.js oder ähnliches. Wäre direkt interessant zu beobachten ob der Speicher weniger stark ansteigt wenn die Energieflussanzeige direkt ab reboot verwendet wird.

Ich werde das mal ausprobieren. Wenn ich es nicht schon getan habe, stelle ich morgen mal um.

Hier die Verläufe für verschiedene Anzeigeseiten. Die Energieflussanzeige scheint am sparsamsten zu sein:

Das Default-Profil hat mittleren Speichervollauf und exponentielle Steigerung der CPU-Last

Die Ladepunktanzeige hat sehr niedrige CPU-Last, der Speicher läuft aber sehr schnell voll (Logging?)

Die Energieflussanzeige hat eine asymptotische, niedrige CPU-Last und geringen Speichervollauf (vor kurzem war wohl garbage collection?)