Repository navigation
High memory usage and database bloat in long-running OpenCode instances #16777
Description
Description
A long-running OpenCode server instance (2+ days) consumes 1.76 GB (602 MB RSS + 1.15 GB swap) on an 8 GB system. The SQLite database grows to 1.99 GB with no automatic cleanup — 1,706 sessions spanning 53 days, 274K parts (1.49 GB) never pruned.
Root causes identified:
- No data retention — sessions are only soft-archived, never deleted
- auto_vacuum = OFF — deleted data never reclaims disk space
- No periodic WAL checkpoint — WAL file grows unbounded during long sessions
- Compaction marks parts but keeps full data — dead weight in SQLite
- Bash tool output accumulates unboundedly — verbose commands can grow to hundreds of MB in the output string
- Edit tool Levenshtein uses O(n×m) matrix — can spike to ~400 MB for 10K char strings
- FileTime per-session tracking never pruned — slow memory leak over instance lifetime
- RPC pending map has no timeout — orphaned promises leak if workers die
- LSP diagnostics Map grows monotonically — empty entries never deleted
Measured metrics:
| Metric | Value |
|---|---|
| Main process RSS | 602 MB |
| Main process swap | 1.15 GB |
| Peak RSS (VmHWM) | 1.64 GB |
| SQLite DB size | 1.99 GB |
| DB parts table | 1.49 GB |
| Sessions | 1,706 (never auto-deleted) |
| auto_vacuum | OFF |
Supersedes #16729 which was auto-closed due to template formatting.
Plugins
No plugins
OpenCode version
0.1.44 (dev build)
Steps to reproduce
- Run
opencode serveon a machine with 8 GB RAM - Use it actively for 2+ days with multiple worktrees
- Monitor RSS with
ps auxor/proc/<pid>/status— memory grows monotonically - Check
opencode.dbfile size — grows without bound since archived sessions are never deleted
Screenshot and/or share link
N/A
Operating System
Ubuntu 22.04 (Linux x86_64, 8 GB RAM, 16 GB swap)
Terminal
N/A (headless server mode via opencode serve)
Activity
github-actions commentedon Mar 9, 2026
This issue might be a duplicate of existing issues. Please check:
If the fixes you're tracking (e.g., PR #16730) are already captured under #16697, it may be worth coordinating there rather than maintaining a separate issue.
thdxr commentedon Apr 2, 2026
Closing in favor of #20695 where we're collecting all memory-related problems. Please follow that issue for updates.
chncaesar commentedon Jul 22, 2026
I hit the same problem — my DB was 1.3 GB with 56% freelist pages (only 525 MB of live data). I built a small tool to handle the cleanup safely:
It checkpoints WAL, verifies integrity before and after, creates a timestamped backup, enables
auto_vacuum = INCREMENTAL, runs VACUUM with progress, and re-enables WAL. Refuses to run while OpenCode has the DB open (fuser check). Took mine from 1.3 GB to ~578 MB.Might help others while the upstream fix lands: https://github.com/chncaesar/opencode-db-clean