What problem does it solve?
Self-hosted Activepieces workers that grow memory until they are OOM-killed are hard to diagnose: pm2 restarts hide the crashes, heap snapshots contain secrets so they cannot be shared, and it is easy to profile the wrong process. This Skill provides a complete on-host procedure to confirm OOM kills, separate JS-heap leaks from native growth, snapshot a live worker without exfiltrating data, and walk the retainer path back to the leaking code.
Core Features & Use Cases
- OOM confirmation: Distinguish cgroup OOM kills of pm2 children from container restarts using docker inspect, pm2 lists, and dmesg, including the 15-character process-name truncation pitfall.
- Heap vs native classification: Compare V8 used heap against RSS to decide whether a heap snapshot will even help before taking one.
- Safe in-place snapshotting: Raise the cgroup limit temporarily, drive the V8 inspector over CDP with the shipped ws library, force garbage collection first, and stream the snapshot to disk without uploading it.
- Retainer-path analysis: Parse the snapshot offline in a throwaway container, build a constructor histogram, and BFS the retainer path to name the exact variable holding the memory.
- Use Case: A self-hoster reports worker memory correlating with pod age; you identify the sandbox process, snapshot it, and trace a 90 MB retained string back to a module-level cache keyed by flow bundle path.
Quick Start
Diagnose why my Activepieces worker container keeps growing in memory and getting OOM-killed, and find the code responsible.