1.8 KiB
1.8 KiB
| type | source_url | retrieved | title | author | tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| other | https://t.me/c/3839640481/15312 | 2026-09-24 | Netbits — PLUR1BUS RAM-Diagnose: LanceDB-Nativlib-Mehrfachladung und V8-Heap | Netbits ⚡️ Stachelbanane (@NetLightning) |
|
Netbits — PLUR1BUS RAM-Diagnose (24.09.2026)
Netbits (@NetLightning) veröffentlichte am 24.09.2026 im OME-Topic „Plur1bus Memory System" eine Messung des RAM-Verbrauchs von Gateway/PLUR1BUS.
Manifeste: kein RAM-Faktor
- Liegen auf ZFS (
/, 74 MB), nicht in tmpfs — also nicht im RAM - Nicht mmap't, nur 8 offene Handles des Gateways
- Der Prune brachte 176 MB → 74 MB — das war Plattenplatz, nicht RAM
Der tatsächliche RAM-Befund (Gateway, gemessen)
- 6 separate Kopien der LanceDB-Nativlib im Adressraum — je eigene Inode (
links=1, Inodes 1542420…1691715), zusammen ~625 MB RSS; eine einzelne Kopie 132,9 MB - Ursache: das Plugin lädt aus verschiedenen
/var/tmp-Build-Kopien, jede mapped ihre eigene Nativlib — dieselbe Krankheit wie zuvor bei den Crons - 65 Build-Dirs liegen unter
/var/tmp, nur 6 sind aktiv gemappt - Die 7,6 GB unter
/var/tmp/openclaw-gatewaysind ZFS = Platte, nicht RAM
Der eigentliche Brocken
- V8-Heap (
anon) ~3,8 GB — der JS-Heap dominiert, nicht LanceDB - Gesamt-cgroup: 4275 MB; davon
file364 MB (davonfile_mapped79 MB)
Einordnung (Netbits)
Die 625 MB sind real, aber file-backed → unter Speicherdruck reclaimable. Der harte Posten bleibt der V8-Heap. Die 59 unbenutzten Build-Dirs wegzuräumen bringt ~6–7 GB Platte, null RAM. Für RAM würde nur ein Gateway-Neustart die 6 Libs auf 1 reduzieren — den fährt Netbits nicht aus der eigenen Shell, nur der Watchdog darf das.