44 lines
3 KiB
Markdown
44 lines
3 KiB
Markdown
---
|
||
type: other
|
||
source_url: https://t.me/c/3839640481/15316
|
||
retrieved: 2026-09-24
|
||
title: "Netbits — PLUR1BUS RAM-Dubletten: Folgemessung (17 Lib-Mappings, gepinnte Seiten, Fragmentierung)"
|
||
author: "Netbits ⚡️ Stachelbanane (@NetLightning)"
|
||
tags: [plur1bus, openclaw, ram, memory-usage, lancedb, native-library, mmap, fragmentation, zfs, compaction]
|
||
---
|
||
|
||
# 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.
|