# Memory not released to default levels: \`ray::IDLE\` Processes Not Released\*\*

**URL:** <https://discuss.ray.io/t/memory-not-released-to-default-levels-ray-idle-processes-not-released/23295>\
**Category:** Ray Serve\
**Created:** [November 1, 2025, 10:22am UTC](https://discuss.ray.io/t/memory-not-released-to-default-levels-ray-idle-processes-not-released/23295 "2025-11-01T10:22:46Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![RunLLM](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ray.io/runllm/32/8249_2.png) [@RunLLM](https://discuss.ray.io/u/RunLLM)\
**Post date:** [November 1, 2025, 10:23am UTC](https://discuss.ray.io/t/memory-not-released-to-default-levels-ray-idle-processes-not-released/23295/2 "2025-11-01T10:23:31Z")

</div>

Ray’s ray::IDLE processes not releasing memory after task completion is a known issue, especially under heavy or long-running workloads. This is due to Ray’s worker processes retaining memory allocations even when idle, and the memory is only reclaimed when the worker is killed—typically when the node approaches the RAY\_memory\_usage\_threshold. Tuning parameters like kill\_idle\_workers\_interval\_ms or RAY\_SERVE\_ENABLE\_PROXY\_GC\_OPTIMIZATIONS often has little effect, and manual gc.collect() calls do not guarantee memory release. This behavior is by design and is widely reported, especially when large objects or high concurrency are involved. The issue is exacerbated by object references lingering in idle workers, and Ray’s memory recycling is not aggressive to avoid performance penalties. There is no configuration to force immediate memory release from idle workers without risking premature worker termination and 500 errors under load. See [Ray documentation on memory debugging](https://github.com/ray-project/ray/blob/releases/2.49.1/doc/source/ray-observability/user-guides/debug-apps/debug-memory.rst), [GitHub issue 52174](https://github.com/ray-project/ray/issues/52174), and [discussions on idle memory](https://discuss.ray.io/t/ray-idle-still-takes-a-lot-of-memory/12982).

Regarding performance regression after upgrading, NumpyStore and increased ray.get/put calls can slow down processing, but other factors include changes in Ray’s internal scheduling, memory management, or object store behavior. Network load (e.g., Triton inference) and library versions can also impact performance, but the main cause of persistent memory usage is Ray’s worker and object store management, not your code or most third-party libraries. Unless you can reduce the size or lifetime of objects, or lower parallelism, there is no general workaround except to accept higher baseline memory usage or tune the memory threshold with caution. For more, see [Ray memory troubleshooting](https://github.com/ray-project/ray/blob/releases/2.49.1/doc/source/ray-observability/user-guides/debug-apps/debug-memory.rst) and [related GitHub issues](https://github.com/ray-project/ray/issues/52174).

Would you like a step-by-step breakdown of how to further diagnose or mitigate this, or more detail on specific Ray parameters?

Sources:

- [GitHub issue 52174](https://github.com/ray-project/ray/issues/52174)
- [Ray Discourse: ray::IDLE still takes a lot of memory](https://discuss.ray.io/t/ray-idle-still-takes-a-lot-of-memory/12982)

Hint: Mention @RunLLM in the post for followups.

---

_[View the full topic](https://discuss.ray.io/t/memory-not-released-to-default-levels-ray-idle-processes-not-released/23295)._