profile-worker-memory

Diagnose worker memory leaks by capturing and analyzing V8 heap snapshots in place.

24.2k|4.1k|Updated Dec 3, 2022
One-click install
npx skills add https://github.com/activepieces/activepieces --skill profile-worker-memory
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: profile-worker-memory
Source: https://github.com/activepieces/activepieces/tree/main/.agents/skills/profile-worker-memory
Command: npx skills add https://github.com/activepieces/activepieces --skill profile-worker-memory

SYSTEM DOCUMENTATION & REQUIREMENTS

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.

Frequently Asked Questions about profile-worker-memory

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose a Node.js worker that keeps getting OOM-killed?

Confirm the OOM kill with docker inspect OOMKilled, pm2 restart counts, and dmesg cgroup messages. Then compare V8 used heap against RSS to decide whether it is a JS heap leak or native growth before taking any snapshot.

How do I take a V8 heap snapshot of a live Node process?

Send SIGUSR1 to open the inspector, connect over CDP on 127.0.0.1:9229, run HeapProfiler.collectGarbage first, then takeHeapSnapshot and stream the chunks to a file. Raise the container memory limit first because serialization allocates.

Why is my container RSS growing while the JS heap stays flat?

Flat heap with growing RSS indicates native memory growth from sources like isolated-vm, buffers, or native addons, not a JavaScript leak. A heap snapshot will show nothing useful in that case, so investigate native allocations instead.

Can I send a heap snapshot to a vendor for analysis?

No. Heap snapshots contain connection tokens, API keys, and customer step data verbatim. Keep the snapshot on the host, parse it there or in a throwaway container, and only share redacted aggregate histograms and retainer paths.

Why does the V8 inspector WebSocket connection fail from Node?

Node's global WebSocket cannot complete the inspector handshake; the socket dies after connecting. Use the ws package already shipped in the image with perMessageDeflate disabled and maxPayload set to 0.

How do I find which code is retaining leaked memory?

Build a parent map via BFS from the snapshot's root node, then walk parents back from the offending node printing edge names. The property names on the retainer path correspond to the variable names in the source code holding the memory.