DocKr / RAM-Cleanup

What it is and why you'd bother

If VRAM is where ComfyUI gets tight fast, system RAM is where it bleeds slowly. Run a long batch, a video pipeline, or a leaky custom node you can't be bothered to hunt down, and memory usage creeps up even when nothing is obviously wrong. DocKr / RAM-Cleanup is the sibling node in the Comfyui_BatchClear_DocKr pack, built to attack that creep on a schedule, same as its VRAM brother. The first thing to know before you get excited: it's the more Windows-flavored of the two.

How it actually works

The mechanism in one breath: the same batch_index % batch_clear gate, the same gc.collect() plus CUDA-cache sweep, then it goes after the OS. On Windows it calls EmptyWorkingSet on every process it can open, SetProcessWorkingSetSize(-1, -1, -1) to trim its own working set, and SetSystemFileCacheSize to shrink the file cache. It retries up to retry_times times, a second apart, stopping early once free memory exceeds double your critical_threshold_mb, and it logs the before/after usage percentage and how many MB it clawed back so you can see whether it did anything. On Linux, though, all of those OS-level calls are gated behind a platform.system() == "Windows" check. What remains is the Python-side gc plus malloc_trim(0) - which trims the Python process's glibc heap, not the OS page cache. So: on Windows this is a genuine RAM reclaim tool; on Linux it's a modest coaxer.

The inputs that matter

The knobs that matter:

• clean_processes - the one to be careful with. Default True means every clean walks all system processes and trims their working sets, which can make the whole OS feel laggy for a moment right after a run. Leave it off unless you actually watch RAM climb.
• clean_dlls / clean_file_cache - Windows-only trims. SetSystemFileCacheSize also needs admin rights and typically fails silently without them.
• retry_times - how many one-second passes before giving up (1–10).
• batch_clear + batch_index - the same schedule logic as the VRAM node. README suggests every 10 runs; the shipped default is 30.
• bypass_all - skip a run without deleting the node.

Outputs mirror the VRAM node: anything (a pass-through of any type, so you can wire the graph through it) and batch_index (the counter, so you can chain RAM and VRAM cleanup on one schedule). The README's example is exactly that: VRAM-Cleanup first, then RAM-Cleanup, with the counter feeding between them.

Installing it

Install is the same pack, so if you already run Comfyui_BatchClear_DocKr you're done:

cd ComfyUI/custom_nodes
git clone https://github.com/DocWorkBox/Comfyui_BatchClear_DocKr.git
pip install -r requirements.txt   # just psutil

then restart. Or search Comfyui_BatchClear_DocKr in ComfyUI Manager. No models, no heavy deps.

What actually bites

What'll bite you: the shipped defaults are aggressive (clean_processes=True, clean_dlls=True, retry_times=3) while the README's recommended set is the conservative one (clean_processes=False, clean_dlls=False, retry_times=1). Start conservative and dial up if you actually see creep. And manage expectations: RAM cleanup won't fix an OOM crash mid-inference - that's a VRAM/offload problem, and ComfyUI's --highvram mode keeps models resident no matter what this node wants - and it won't clear the execution cache, which is the other half of the menu's "Unload Models and Execution Cache" button. It's for slow memory creep over long sessions. On Windows it genuinely helps; elsewhere, set it, forget it, and check the console log to see if it earned its place.