Oak repository growth
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Platform engineers | Disk-alert responders |
Growth is normal; the QUESTION is what kind
disk alert
├─ segmentstore growing, content flat → revisions not being reclaimed → revision GC lane
├─ datastore growing → binaries: DAM ingest? versions? datastore GC running?
├─ /var trees exploding → workflow/audit/event purges not running
└─ index dirs growing → over-broad index definitions (index lane)Attribute first (disk-usage report / oak-run explore / JMX repository stats) — the fix differs completely per lane.
Revision GC lane (TarMK)
- Is online revision cleanup actually RUNNING and COMPLETING? (Operations → Maintenance status + gc log lines in error.log). "Configured" ≠ "completing" — interrupted/cancelled runs reclaim nothing (maintenance).
- Classic blocker: too little free disk to compact (needs headroom to rewrite segments) — the death spiral where the fix needs the space the problem consumed. Act before 85%; at 95% you're into offline compaction with downtime, or emergency disk.
- Long-running open sessions can pin old revisions — leaked resolvers in code (logging/session hygiene house rules) show up HERE, months later.
/var lane
Workflow instances, audit events, Sling eventing jobs: check counts, then fix the purge configs and run catch-up purges in windows (huge single purges are themselves load — chunk them). Root cause is usually "purge jobs never configured after go-live" (archiving decisions).
Version lane
Version storage grows with every activation (session 9). No version purge configured = unbounded. Configure per retention decision, run initial catch-up carefully (it's a big delete — window it).
After reclaiming
Trend the graph weekly (operating rhythm): healthy = sawtooth (grow, GC reclaims); unhealthy = staircase. The staircase is this page's early-warning signature — catch it at month 2, not month 9.