Netbits — PLUR1BUS RAM-Dubletten: Folgemessung (24.09.2026, 23:38)

Netbits (@NetLightning) veröffentlichte im OME-Topic „Plur1bus Memory System" die Folgemessung nach dem Gateway-Neustart von 18:45. Gemessen 23:38.

RAM — echtes Doppelproblem

Der Gateway hat 17 Kopien derselben Native-Lib gemappt: lancedb.linux-x64-gnu.node, je 139 MB auf Platte.
PSS-Summe: 152,6 MB im RSS; davon 115,7 MB aus gelöschten Pfaden — 15 der 17 zeigen auf /var/tmp/openclaw-plugin-build-*/package-52/…, und diese Ordner existieren nicht mehr.
Kern: Eine gemappte Datei, die gelöscht wurde, kann der Kernel nicht mehr auslagern — die Seiten sind gepinnt, bis der Prozess sie entmappt. Freigabe nur per Neustart.
Mechanismus: Jeder Plugin-(Re)Load packt das Paket nach /var/tmp, mappt die Lib, löscht danach das Verzeichnis. Das Mapping bleibt zurück.

Platte — Dubletten und Ballast

Extension 4×: extensions/memory-lancedb-namespaced 272M + install-backups/… 271M + backups/plugin-memory-lancedb-7.2.2-* 273M + -copy 273M = ~1,09 GB
/var/tmp: 597 Build-Reste vom 21.–24.09.; Größe schwankt stark — in geprüften Resten war die Lib schon weg (30–57 KB), also Disk-Rest statt RAM-Fresser
Legacy-SQLite parallel zu Lance: luna.sqlite.migrated 76M + main.sqlite.migrated 20M + 2 tmp-Orphans 28M = ~124 MB toter Ballast (Memory liegt längst in Lance, die SQLites sind Migration-Relikte)

Drei Stores nebeneinander

lancedb-namespaced/<agent> — der aktive (luna 742M)
_neo/workspaces/… 67M — zweiter Datensatz mit denselben Workspaces, als JSONL-Ledger + vectors.0.f32 (42M + 13M)
.plur1bus-shared/workspaces/w-83bb… 57K — ein dritter
Leer und nutzlos: bernhardine, control, defaults, heisenberg, list (je 512 B)

Fragmentierung

luna-Store: 31.529 .lance-Dateien, 82 % davon unter 1 KB. Scheinbar 117 MB, belegt 742 MB — ZFS-Overhead durch Kleinstdateien.

RAM-Stand

3,68 GB current, Peak 3,96 GB, anon 3,46 GB. Der Neustart hat von 6,2 GB auf 3,7 GB gedrückt; das Wachstum läuft aber wieder (vorhin rund 540 MB/Stunde, jetzt bei 5,3 h Laufzeit). Die gemappten 115 MB sind ein fester Sockel, kein Wachstum. Das eigentliche Wachstum kommt woanders her.

Fazit (Netbits)

Doppelt ist vor allem die Mechanik — 17 Mappings derselben Lib, 4 Extension-Kopien, 3 Datenspeicher, 2 SQLite-Generationen. Der RAM-Gewinn durch Aufräumen läge bei rund 115 MB plus dem, was Neustarts künftig sparen. Angeboten: /var/tmp leeren, doppelte Extension-Backups und Migration-SQLites in Quarantäne, leere Namespaces weg.

3 KiB Raw Blame History Unescape Escape