Global Memory Trim Now

Here's the honest pitch: this node is probably not why you installed the pack. The whole trick of ComfyUI-Global-Memory-Trim is a global patch that trims ComfyUI's CPU/native heap around every node execution - it installs itself the moment the custom node loads, no workflow wiring required. GlobalMemoryTrimNow exists for the times you want to see it happen, or force a trim on demand. Think of it as a manual release valve with a live RSS readout bolted on.

Why you'd reach for it

If your ComfyUI is a WSL2 box that keeps generating images and video fine, then starts stalling or outright wedging after hours of model switching, you're likely hitting retained glibc heap - memory that Python's garbage collector can't get back because large buffers went through native allocations (PyTorch, NumPy, OpenCV, Pillow) and the pages never returned to the OS. Community threads on this are full of people watching RSS climb past 40–50 GB until the OOM killer steps in; one well-known fix is the pair of MALLOC_*_THRESHOLD_ env vars, and this pack is a fancier relative of that trick, applied around every node boundary.

That's the pack's real job. This node's job is narrower: give you a manual trim plus the numbers to prove it did something.

How it works

The pack monkey-patches ComfyUI's execution.get_output_data at import time. Around each node execution it can run gc.collect() followed by glibc's malloc_trim(0) via ctypes, which asks the allocator to return freed heap pages to the OS. RSS is read straight from /proc/self/status. When you fire GlobalMemoryTrimNow, it just calls that same trim_native_heap() function with phase="manual" - same code path the global patch uses.

Behavior is governed by environment variables, not node inputs. The ones that matter:

• COMFYUI_GLOBAL_TRIM_BEFORE / _AFTER - trim before and/or after nodes (after is on by default, before is off because it's more aggressive).
• COMFYUI_GLOBAL_TRIM_INTERVAL - trim every N opportunities; the README's performance profile uses 3.
• COMFYUI_GLOBAL_TRIM_MIN_RSS_MB - skip trims until RSS reaches this threshold (0 = always).
• COMFYUI_GLOBAL_TRIM_GC - run gc.collect() first (on by default).

Set them before launching ComfyUI. The status string this node returns is a dump of the result dict, which includes enabled, patched, rss_before_mb, rss_after_mb, delta_mb, malloc_trim_rc, and duration_ms.

The inputs that matter

Only two, both boolean:

• trigger (default true) - run the trim now. Set it to false and the node does nothing except report the last trim result, which is handy for turning the node into a passive monitor you can leave in the graph.
• force_even_if_disabled (default false) - bypass COMFYUI_GLOBAL_TRIM=0 and the interval/RSS skips for this one call. Use it when you've tuned the patch off but want to test trim manually.

Outputs: status (STRING, the result dump), rss_before_mb, rss_after_mb, and delta_mb (all INT, in MB). Wire them into a Text Display node, or skip them - the node works fine as a standalone fire-and-forget trigger.

Installing

The pack has no Python dependencies beyond the standard library and downloads no model files. Clone it into custom_nodes and restart:

cd ~/ComfyUI/custom_nodes
git clone https://github.com/xmarre/ComfyUI-Global-Memory-Trim

Or use ComfyUI Manager and search for "Global Memory Trim". On startup you should see a line like Installed global memory trim patch: enabled=True before=True after=True ... in the console.

Common issues

• It's not a VRAM tool. This is the #1 misunderstanding. It frees CPU/native heap, not CUDA memory - it won't unload models or fix CUDA allocator fragmentation. If your problem is VRAM OOM, this is the wrong pack.
• It's Linux-only. malloc_trim lives in glibc; on Windows or macOS the patch is a harmless no-op, and the manual node will report a "non-linux no-op". Don't install it there expecting anything.
• Small or zero delta. That's normal - if there's nothing to release, malloc_trim(0) returns quickly and delta_mb stays near 0. A negative delta means RAM went up during the trim's own work, usually nothing to panic about.
• "interval skip" / "rss below threshold" in the status. That's the guards working as designed, not a failure.

A couple of WSL-specific pointers from the README's performance profile: leave PYTORCH_CUDA_ALLOC_CONF unset and don't add --disable-cuda-malloc, and consider --disable-async-offload --disable-pinned-memory - those transfer paths are fragile under WSL.