the memory of dify-api was not released

[OPSTime]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

However, it was found that after the stress test, the memory of dify-api was not released, and the memory usage did not decrease.

✔️ Expected Behavior

Automatic memory reclamation

❌ Actual Behavior

Not automatically reclaimed

[dosubot]

This is a known challenge with long-running Python services like dify-api, especially under stress. The API uses Python 3.11, Flask, Gunicorn (gevent worker), SQLAlchemy, and Redis, but there are no explicit memory cleanup routines for large in-memory objects, background threads, or caches. The dataset retrieval pipeline, in particular, can accumulate large lists and threads that keep memory alive until all callbacks and tasks finish, which can prevent memory from being released automatically after heavy load or stress testing. Persistent Redis connection pools and optional client-side caches may also contribute to long-lived allocations that aren't reclaimed until the process restarts or the objects are explicitly cleared [1] [2].

There are no recent code changes or documentation addressing memory management or resource cleanup in dify-api [3]. The default Docker deployment does not set explicit memory limits or garbage collection tuning, so memory may only be reclaimed when the container or worker is restarted [4].

To investigate further or mitigate, you can:

• Use Python memory profiling tools like tracemalloc, objgraph, heapy, or memory_profiler to identify what objects are being retained.
• Consider enabling Gunicorn worker recycling (using --max-requests and --max-requests-jitter) to periodically restart workers and reclaim memory.
• Explicitly clear large in-memory lists or caches after use, and ensure background threads are not holding references longer than needed.
• If possible, monitor which endpoints or request patterns cause memory growth.

If you have memory profiler output, heap dumps, or logs showing which objects are retained, sharing those details would help pinpoint the source of the leak. Let me know what monitoring or profiling tools you've tried and if you see any patterns in memory usage growth.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}