Skip to content

Plex memory optimization plan

Status: sandbox on-demand lifecycle authorized and executed on 2026-09-22. Five ERP sandbox containers stopped with volumes preserved; two dependent development-store timers disabled while idle. Other optimization proposals remain planning only. See sandbox-workflow.

Measured baseline

16 GiB physical RAM; Linux reports 15.48 GiB usable, approximately 12.93 GiB used and 2.55 GiB available at the first sample. Buffers/cache were 3.35 GiB; do not add this to available memory or assume every cached page is immediately reclaimable. All 4 GiB swap was allocated. Short vmstat samples showed 0 then 16 KiB/s swap-in, zero swap-out, and memory PSI avg10 0.00/avg60 0.01: no sustained thrashing was observed in this short window. This is not peak-load evidence or proof of no leak.

70 containers were running. Second Docker CLI snapshot, grouped by service:

Service group Approximate memory
Sandbox InvenTree ERP 2.36 GiB
Production InvenTree ERP 1.67 GiB
Postiz and supporting services 1.99 GiB
Metabase and supporting services 1.12 GiB
Store 0.24 GiB
Other containers combined 2.77 GiB
Total container readings 10.15 GiB

Docker's Linux CLI excludes inactive file cache from its memory reading. Container totals are approximate working-set accounting, not a complete unique host process-memory measurement. Do not add process RSS on top of these rows: that counts the same container processes twice. Host services, AI development sessions, kernel memory and other accounting differences explain why host usage is not identical to the table. Both Android rehearsal services were inactive. GNOME shell/Xorg RSS were only about 60/10 MiB at this snapshot, so disabling the desktop is not a high-value first target.

Proposed order — not executed

  1. Capture a 15–30 minute representative baseline, plus longer normal/peak samples before production tuning: MemAvailable, PSI, swap activity, grouped container peaks, request latency and ERP queue delay. Check active task ownership first.
  2. Make sandbox ERP on-demand when no task uses it, preserving its data and documented start/health checks. Its current 2.36 GiB footprint is the largest clear optional target; actual returned headroom must be measured. If it must stay online, benchmark 1 web/1 background worker instead of the configured 4/4. This is a proposed test setting, not a proven safe configuration. Confirm no parallel agent, tester or scheduled task depends on the sandbox before stopping.
  3. Audit leftover development sessions and verification containers by owner and active work. Two erp-verify-pg-* containers created September 20 use only about 51 MiB together; cleanup would be housekeeping, not the main memory win. Names and age alone do not establish abandonment. Never kill current AI jobs blindly.
  4. Only after sandbox results, consider production ERP 2 web/2 background workers versus current 4/4. InvenTree supports configurable worker counts. Benchmark representative requests, long jobs and queue drain. Predetermine rollback on latency regression, errors, sustained queue growth or saturation. Do not promise a numerical saving without a measured before/after.
  5. Measure Metabase heap, garbage collection and peak query concurrency before considering an explicit JVM heap budget. Heap is only part of process memory; reserve non-heap/native headroom. Metabase documents JVM memory controls. Its present ~1.12 GiB stack is not by itself evidence of excessive allocation.
  6. Keep production Postiz/Temporal and databases available for scheduled posts. Assess version-supported heap/worker settings and load only after the simpler changes. Hard caps without application budgets can cause OOM kills and missed work; they are guardrails, not an optimization by themselves.
  7. Reassess Android with the reclaimed headroom and normal guest allocation. A 32 GiB RAM upgrade remains useful for concurrent development plus production, but evaluate the free sandbox optimization before deciding it is necessary.

Do not drop Linux caches as a memory fix, run swapoff on the full swap area, or restart everything to make a short-term graph look better. Increasing swap or using zram can be evaluated separately; neither replaces a measured RAM budget for interactive Android automation.

RAM module inventory confirmed

The user supplied SMBIOS output: one 16 GB DDR4 unbuffered desktop DIMM in DIMM3; DIMM1/2/4 empty. Rated speed 2667 MT/s, configured 2400 MT/s, 1.2 V, rank 1; part number blank. Canonical hardware facts are in ../map/objects/host/machine. A proposed 32 GB upgrade can add one compatible 16 GB module without replacing the current stick. The four-slot desktop configuration supports Dell's documented 64 GB limit. Exact product/paired slot placement remains to be checked before purchase. Optimization work remains planning only.

Review evidence

One bounded, tool-free, Landlock-confined review explicitly requested gpt-5.6-luna through the subscription CLI; resolved model version was not reported. Primary checked the plan against fresh container sums and corrected rough Postiz arithmetic and overly broad cache/accounting language. Source was fresh codex-app-server allowance telemetry (30% weekly used at dispatch); no paid API fallback. The background runner had no running job at inspection.