MetaCore: mem_limit 8g/6g -> 1g (SQLite store idles ~70-160 MB, 568 MB peak)

Apps/MetaCore/docker-compose.yml

@@ -10,18 +10,15 @@ services:
     # Hard RAM cap, swap disabled (memswap_limit == mem_limit) → OOM
     # instead of swap. Both values must move together or swap comes back.
     #
-    # Raised 768m -> 1536m (2026-08-26): on watch.nsl.sh the Redis working set
-    # ran at 73-97% of 768m, i.e. one indexing burst away from an OOM kill that
-    # takes the record store (and every service reading it) down with it.
-    # 1536m puts steady state near 30%.
-    #
-    # Raised 1536m -> 6g (2026-09-30): the record index costs ~40 KB of RAM per
-    # record, and watch.nsl.sh's working set reached 4.8 GiB (tens of
-    # thousands of records). A cap is a ceiling, not a reservation — a small
-    # library still uses a few hundred MB — so a generous one costs nothing
-    # until the library grows into it.
-    mem_limit: 6g
-    memswap_limit: 6g
+    # Lowered to 1g (2026-10-19, meta-core 1.2.0). The store is an embedded
+    # SQLite file now (no Redis, no in-memory search copy): on watch.nsl.sh,
+    # 169k records, meta-core idles at ~70-160 MB and peaked at 568 MB during
+    # a full counter rebuild (POST /api/schema/rescan) — the heaviest operation
+    # it has. Page cache for the database file is charged here too but is
+    # reclaimable. History: 768m → 1536m (Redis working set) → 6g → 8g (the
+    # Redis-era in-memory index, ~30 KB/record, OOM-killed repeatedly).
+    mem_limit: 1g
+    memswap_limit: 1g
     hostname: metacore-app
     restart: unless-stopped
     privileged: true