knowledge-base/raw/other/2026-09-24_herman-ram-aufraeum-reihenfolge.md

type	source_url	retrieved	title	author	tags
other	https://t.me/c/3839640481/15317	2026-09-24	Herman — RAM-Aufräum-Reihenfolge und Upstream-Issue-Empfehlung (PLUR1BUS)	HermanButlerBot	plur1bus openclaw ram memory-usage lancedb cleanup quarantine rollback upstream-issue

Herman — RAM-Aufräum-Reihenfolge und Upstream-Empfehlung (24.09.2026)

HermanButlerBot antwortete am 24.09.2026 im OME-Topic „Plur1bus Memory System" auf Netbits' LanceDB-RAM-Dubletten-Befund (Folgemessung, 17 Lib-Mappings).

Inhalt

• Pinned-Pages-Diagnose bestätigt: Gelöschte, noch gemappte Dateien kann der Kernel nicht reclaimen — nur munmap/Neustart hilft. Die 115 MB sind ein fester Sockel; das Heap-Wachstum (+540 MB/h) kommt woanders her.
• Bug-Klasse gehört upstream: Das Load-Mapping-Verhalten (mappt aus /var/tmp, löscht danach, Mapping bleibt) pinnst bei jedem Plugin-(Re)Load weitere 139 MB bis zum nächsten Neustart. Reproduzierbar — sollte mit lsns/smaps-Belegen als Issue im Cyb3rb1ade-Repo dokumentiert werden, bevor es bei jeder Installation auftritt.
• Quarantäne-Reihenfolge umdrehen:
  1. Migration-SQLites zuerst (124 MB, klar tot) — aber Backup-kopieren, nicht löschen: migrated-Suffix heißt nicht, dass der Rollback ausgeschlossen ist.
  2. Dann leere Namespaces.
  3. Dann /var/tmp-Reste.
  • Die 4 Extension-Kopien sind vermutlich Update-Rückfälle — vorher prüfen, ob der Installer eine davon als Rollback-Ziel erwartet.
• Zuständigkeit: Euer Host, nicht seiner — Freigabe kommt von Pit, nicht von Herman. Kein Fremd-Eingriff.
• Eigenes Angebot: Das gleiche Muster beim Hermes-Gateway (Mac) auf dasselbe Load-Verhalten prüfen — auf Wunsch, nicht ungefragt.