langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Memory leak #7124

New Issue
Closed
opened 2026-02-21 18:19:01 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 18:19:01 -05:00
Owner
Copy Link
Copy Source

Originally created by @Alex-lsky on GitHub (Dec 9, 2024).

Self Checks

  • 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 (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.13.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

The memory footprint of dify,api, and work containers deployed with docker is always monotonically increasing, and memory is not released when calls are stopped, I have verified this issue in multiple versions (0.8-0.13.1) and in multiple environments (docker, k8s)
image

✔️ Expected Behavior

When the call is stopped, the memory usage drops

❌ Actual Behavior

The memory of the api and work is always growing until it takes up about 6G and the LLM call efficiency becomes so low that the container must be restarted to alleviate it

Originally created by @Alex-lsky on GitHub (Dec 9, 2024). ### Self Checks - [X] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [X] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [X] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [X] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.13.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce The memory footprint of dify,api, and work containers deployed with docker is always monotonically increasing, and memory is not released when calls are stopped, I have verified this issue in multiple versions (0.8-0.13.1) and in multiple environments (docker, k8s) ![image](https://github.com/user-attachments/assets/2f5db6a4-9301-432e-9110-c942e22ab347) ### ✔️ Expected Behavior When the call is stopped, the memory usage drops ### ❌ Actual Behavior The memory of the api and work is always growing until it takes up about 6G and the LLM call efficiency becomes so low that the container must be restarted to alleviate it
yindo added the 🐞 bug label 2026-02-21 18:19:01 -05:00
yindo closed this issue 2026-02-21 18:19:01 -05:00
yindo commented 2026-02-21 18:19:02 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 9, 2024):

@Alex-lsky Hello! I'm here to help you with any bugs, questions, or contributions. Let's work together to solve this issue.

It seems like you're experiencing a memory leak issue with the Dify 'api' and 'work' containers, where memory usage continuously increases until it affects performance. Unfortunately, I couldn't find specific information about known memory leaks in the Dify documentation or previous issues. However, here are a few steps you might consider to address this problem:

  1. Update to Latest Version: Ensure you are using the latest version of Dify, as updates may contain bug fixes related to memory management.

  2. Monitor Resource Usage: Use monitoring tools to track memory usage over time. This can help identify patterns or specific operations that lead to increased memory usage.

  3. Adjust Configuration Settings: Review and adjust configuration settings related to memory usage, such as PostgreSQL and OpenSearch parameters, to optimize resource allocation [1].

  4. Investigate Code for Leaks: If you have access to the codebase, investigate areas where memory might not be properly released, such as long-lived objects or unclosed resources.

  5. Limit Resource Usage: Set memory limits on your Docker containers to prevent them from consuming excessive resources. This can be done using Docker's resource management options.

  6. Restart Strategy: Implement a restart strategy for your containers to periodically release memory, especially if a long-term fix is not immediately available.

If these steps do not resolve the issue, further investigation into the specific operations or code paths causing the memory increase may be necessary.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other

@dosubot[bot] commented on GitHub (Dec 9, 2024): <!-- Greeting --> @Alex-lsky Hello! I'm here to help you with any bugs, questions, or contributions. Let's work together to solve this issue. <!-- Answer --> It seems like you're experiencing a memory leak issue with the Dify 'api' and 'work' containers, where memory usage continuously increases until it affects performance. Unfortunately, I couldn't find specific information about known memory leaks in the Dify documentation or previous issues. However, here are a few steps you might consider to address this problem: 1. **Update to Latest Version**: Ensure you are using the latest version of Dify, as updates may contain bug fixes related to memory management. 2. **Monitor Resource Usage**: Use monitoring tools to track memory usage over time. This can help identify patterns or specific operations that lead to increased memory usage. 3. **Adjust Configuration Settings**: Review and adjust configuration settings related to memory usage, such as PostgreSQL and OpenSearch parameters, to optimize resource allocation <sup>[[1]](https://github.com/langgenius/dify/blob/main/docker/.env.example)</sup>. 4. **Investigate Code for Leaks**: If you have access to the codebase, investigate areas where memory might not be properly released, such as long-lived objects or unclosed resources. 5. **Limit Resource Usage**: Set memory limits on your Docker containers to prevent them from consuming excessive resources. This can be done using Docker's resource management options. 6. **Restart Strategy**: Implement a restart strategy for your containers to periodically release memory, especially if a long-term fix is not immediately available. If these steps do not resolve the issue, further investigation into the specific operations or code paths causing the memory increase may be necessary. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/ffd72ce0-2181-4143-997f-54839e9c86dc?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/ffd72ce0-2181-4143-997f-54839e9c86dc?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/ffd72ce0-2181-4143-997f-54839e9c86dc?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/ffd72ce0-2181-4143-997f-54839e9c86dc?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/ffd72ce0-2181-4143-997f-54839e9c86dc?feedback_type=hallucination) | [Other](https://app.dosu.dev/response-feedback/ffd72ce0-2181-4143-997f-54839e9c86dc?feedback_type=other)</sup>
yindo commented 2026-02-21 18:19:02 -05:00
Author
Owner
Copy Link
Copy Source

@liangpeihuahua commented on GitHub (Dec 16, 2024):

I also encountered this problem. The memory kept increasing and I had to restart the container to solve it. My version is 0.13.1

@liangpeihuahua commented on GitHub (Dec 16, 2024): I also encountered this problem. The memory kept increasing and I had to restart the container to solve it. My version is 0.13.1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#7124
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?