Loglevel Debug triggert CPU-Last und Speicherverbrauch

[zut]

Der hohe Speicherverbrauch durch das Logging wurde schon in meinem Thread zum Speicherverbrauch des remote support client dating geschrieben, ich möchte das Thema abspalten, weil der Mechanismus ein anderer ist.

Problem: Umschalten auf Loglevel Debug erzeugt hohe CPU -Last und hohen Speicherverbrauch. Der betroffene Prozess ist das main.py.
Der Zustand ist nach wenigen Minuten im Loglevel Debug erreicht (und bleibt auch nach Zurückschalten in den normalen Loglevel.) Korrektur: ich hatte wohl nicht richtig auf Normal (Warnungen und Fehler) zurückgestellt.

Meine Umgebungsbedingungen:
2.1.8 patch1
Smarthome hat 9 Geräte die nur beobachtet und nicht geschaltet werden, DNS ist die Fritzbox, die wiederum Quad9 nutzt.
Kostal Plenticore Plus mit KSEM G1 und BYD HVS sowie ein Mikrowechselrichter an einem Shelly (Shelly-WR). Genutztes Auto ein e-up mit manuellem SoC.

Verlauf der Speichernutzung (man sieht den Moment, wo debug aktiviert wurde, auffällig ist, dass etwa alle 5 Stunden 30 Minuten massiv Speicher allokiert wird.

Screenshot_20251011-205845.png (77.03 KiB) 469 mal betrachtet

Screenshot_20251011-210028.png

(131.98 KiB) Noch nie heruntergeladen

Screenshot_20251011-210323.png (95.74 KiB) 469 mal betrachtet

[LenaK]

Hast Du die Möglichkeit, die ramdisk-Auslastung parallel zum Speicher zu loggen?

[zut]

Ich werde das in nächster Zeit mal versuchen einzubauen.
Bisher kann ich sagen, dass ein Neustart des Hauptprozesses den Speicher freigibt, der Speicher auf debug aber schnell wieder voll läuft. Nach Neustart mit normalem Debuglevel ist es soweit unauffällig.

Ich melde mich hoffentlich in ein paar Tagen mit der Ramdisk-Auslastung.

[zut]

Messung des freien Ramdisk-Speichers läuft. Bisher verhält sich die Belegung unauffällig. Der Hauptprozess wächst und gedeiht. Man sieht ganz gut, wo ich Debug (18:42 Uhr) eingeschaltet habe.

Bildschirmfoto_2025-10-15_15-58-37.png (76.25 KiB) 325 mal betrachtet

[LenaK]

Das Problem ist behoben sowohl im master als auch in 2.1.8-Patch.2.

Danke für deine Hilfe.

[zut]

War verursachte den jetzt das Problem? Aus dem entsprechenden Commit konnte ich mir das nicht ableiten.