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

Dify 1.4.1 does not properly release PostgreSQL connections #14258

New Issue
Closed
opened 2026-02-21 19:16:23 -05:00 by yindo · 4 comments
yindo commented 2026-02-21 19:16:23 -05:00
Owner
Copy Link
Copy Source

Originally created by @tanxianglu on GitHub (May 28, 2025).

Originally assigned to: @laipz8200 on GitHub.

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

1.4.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I deployed it using Docker Compose, The PostgreSQL connection parameters in the .env file have been updated. A screenshot is shown below:

Image After restarting Dify, I made 3 manual invocations. The number of active database connections increased from 8 to 20 and remained at that level. A screenshot of the tool usage is provided below: Image Thank you sincerely for your time and assistance.

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

Originally created by @tanxianglu on GitHub (May 28, 2025). Originally assigned to: @laipz8200 on GitHub. ### 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 1.4.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I deployed it using Docker Compose, The PostgreSQL connection parameters in the .env file have been updated. A screenshot is shown below: <img width="689" alt="Image" src="https://github.com/user-attachments/assets/ffcc25c0-398d-47b1-b76b-bb0676b9be03" /> After restarting Dify, I made 3 manual invocations. The number of active database connections increased from 8 to 20 and remained at that level. A screenshot of the tool usage is provided below: <img width="669" alt="Image" src="https://github.com/user-attachments/assets/9938495f-d376-4f4e-8db8-7328c8b995c4" /> Thank you sincerely for your time and assistance. ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 19:16:23 -05:00
yindo closed this issue 2026-02-21 19:16:23 -05:00
yindo commented 2026-02-21 19:16:24 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 28, 2025):

Hi @tanxianglu! I'm Dosu and I’m helping the dify team.

There is a known issue with PostgreSQL connections not being released properly under heavy load in Dify. The connection pool settings are configurable, and by default, SQLALCHEMY_POOL_SIZE is set to 30 and SQLALCHEMY_MAX_OVERFLOW to 10, with a maximum of 100 connections allowed by default in the Docker environment configuration (reference, reference).

A similar issue was resolved by lowering the SQLALCHEMY_POOL_SIZE to 20, which helped prevent too many concurrent connections from being held open in the managed PostgreSQL database (see issue #13875). You can try adjusting this parameter in your .env file:

SQLALCHEMY_POOL_SIZE=20

After making this change, restart your Dify services. If the problem persists, you may also want to review the SQLALCHEMY_MAX_OVERFLOW and SQLALCHEMY_POOL_RECYCLE settings to ensure they are appropriate for your workload.

These settings are documented in the official configuration files and documentation, and tuning them can help manage connection usage under heavy load (reference).

To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (May 28, 2025): <!-- Greeting --> Hi @tanxianglu! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> There is a known issue with PostgreSQL connections not being released properly under heavy load in Dify. The connection pool settings are configurable, and by default, `SQLALCHEMY_POOL_SIZE` is set to 30 and `SQLALCHEMY_MAX_OVERFLOW` to 10, with a maximum of 100 connections allowed by default in the Docker environment configuration ([reference](https://github.com/langgenius/dify/blob/main/docker/.env.example), [reference](https://github.com/langgenius/dify/blob/main/api/configs/middleware/__init__.py)). A similar issue was resolved by lowering the `SQLALCHEMY_POOL_SIZE` to 20, which helped prevent too many concurrent connections from being held open in the managed PostgreSQL database ([see issue #13875](https://github.com/langgenius/dify/issues/13875)). You can try adjusting this parameter in your `.env` file: ``` SQLALCHEMY_POOL_SIZE=20 ``` After making this change, restart your Dify services. If the problem persists, you may also want to review the `SQLALCHEMY_MAX_OVERFLOW` and `SQLALCHEMY_POOL_RECYCLE` settings to ensure they are appropriate for your workload. These settings are documented in the official configuration files and documentation, and tuning them can help manage connection usage under heavy load ([reference](https://github.com/crazywoola/dify-docs-mintlify/blob/main/zh-hans/getting-started/install-self-hosted/environments.mdx)). <!-- Dosu Comment Footer --> *To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/439eb4f4-b756-4738-8ced-f17f5570020b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/439eb4f4-b756-4738-8ced-f17f5570020b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/439eb4f4-b756-4738-8ced-f17f5570020b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/439eb4f4-b756-4738-8ced-f17f5570020b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/439eb4f4-b756-4738-8ced-f17f5570020b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/439eb4f4-b756-4738-8ced-f17f5570020b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/439eb4f4-b756-4738-8ced-f17f5570020b?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20366)
yindo commented 2026-02-21 19:16:24 -05:00
Author
Owner
Copy Link
Copy Source

@tanxianglu commented on GitHub (May 29, 2025):

Hi @dosu, Thank you very much for your reply. Following your guidance, I modified the .env file. However, when running the load test command,:

wrk -t2 -c20 -d20s -s test.lua --timeout 50s --latency http://IP/v1/chat-messages

PostgreSQL still prompts: FATAL: sorry, too many clients already. Is there any other way to resolve this issue?
Thank you sincerely for your time and assistance.

@tanxianglu commented on GitHub (May 29, 2025): Hi @dosu, Thank you very much for your reply. Following your guidance, I modified the .env file. However, when running the load test command,: `wrk -t2 -c20 -d20s -s test.lua --timeout 50s --latency http://IP/v1/chat-messages` PostgreSQL still prompts: `FATAL: sorry, too many clients already`. Is there any other way to resolve this issue? Thank you sincerely for your time and assistance.
yindo commented 2026-02-21 19:16:24 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 29, 2025):

The error FATAL: sorry, too many clients already means PostgreSQL is hitting its connection limit. Even after adjusting your .env file, this can still happen if the server’s max_connections is too low or if connection pool settings are too aggressive for your workload.

Here are the key steps to resolve this:

  1. Increase PostgreSQL max_connections: In your Docker Compose setup, the default is often 100. You can raise this by setting POSTGRES_MAX_CONNECTIONS to a higher value in your environment configuration. For example, set POSTGRES_MAX_CONNECTIONS=200 or higher, depending on your server resources. Make sure this is reflected in your docker-compose.yaml as well, where it should appear in the command for the db service as postgres -c 'max_connections=...' (reference, issue example).

  2. Tune SQLAlchemy pool settings:

    • SQLALCHEMY_POOL_SIZE controls the number of persistent connections. If this is set too high, it can exhaust your database.
    • SQLALCHEMY_MAX_OVERFLOW allows extra connections above the pool size. Lowering this can help prevent spikes.
    • SQLALCHEMY_POOL_RECYCLE (default 3600 seconds) ensures idle connections are recycled and not left hanging (docs).

    Try settings like:

    SQLALCHEMY_POOL_SIZE=20
SQLALCHEMY_MAX_OVERFLOW=10
SQLALCHEMY_POOL_RECYCLE=1800

  3. Restart all services after changing these settings to ensure they take effect.

  4. Check for other clients: Make sure no other applications or services are using the same PostgreSQL instance and consuming connections.

If you continue to see the error under load, you may need to further increase POSTGRES_MAX_CONNECTIONS or reduce the concurrency of your load test to match your server’s capacity. Also, ensure your server has enough memory to handle the increased number of connections, as each connection consumes resources.

If you need more detailed tuning, please share your current values for SQLALCHEMY_MAX_OVERFLOW, SQLALCHEMY_POOL_RECYCLE, and POSTGRES_MAX_CONNECTIONS, as well as your server’s specs.

To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (May 29, 2025): <!-- Answer --> The error `FATAL: sorry, too many clients already` means PostgreSQL is hitting its connection limit. Even after adjusting your `.env` file, this can still happen if the server’s `max_connections` is too low or if connection pool settings are too aggressive for your workload. Here are the key steps to resolve this: 1. **Increase PostgreSQL max_connections**: In your Docker Compose setup, the default is often 100. You can raise this by setting `POSTGRES_MAX_CONNECTIONS` to a higher value in your environment configuration. For example, set `POSTGRES_MAX_CONNECTIONS=200` or higher, depending on your server resources. Make sure this is reflected in your `docker-compose.yaml` as well, where it should appear in the `command` for the `db` service as `postgres -c 'max_connections=...'` ([reference](https://github.com/langgenius/dify/blob/main/docker/docker-compose.yaml), [issue example](https://github.com/langgenius/dify/issues/19703)). 2. **Tune SQLAlchemy pool settings**: - `SQLALCHEMY_POOL_SIZE` controls the number of persistent connections. If this is set too high, it can exhaust your database. - `SQLALCHEMY_MAX_OVERFLOW` allows extra connections above the pool size. Lowering this can help prevent spikes. - `SQLALCHEMY_POOL_RECYCLE` (default 3600 seconds) ensures idle connections are recycled and not left hanging ([docs](https://github.com/crazywoola/dify-docs-mintlify/blob/main/zh-hans/getting-started/install-self-hosted/environments.mdx)). Try settings like: ``` SQLALCHEMY_POOL_SIZE=20 SQLALCHEMY_MAX_OVERFLOW=10 SQLALCHEMY_POOL_RECYCLE=1800 ``` 3. **Restart all services** after changing these settings to ensure they take effect. 4. **Check for other clients**: Make sure no other applications or services are using the same PostgreSQL instance and consuming connections. If you continue to see the error under load, you may need to further increase `POSTGRES_MAX_CONNECTIONS` or reduce the concurrency of your load test to match your server’s capacity. Also, ensure your server has enough memory to handle the increased number of connections, as each connection consumes resources. If you need more detailed tuning, please share your current values for `SQLALCHEMY_MAX_OVERFLOW`, `SQLALCHEMY_POOL_RECYCLE`, and `POSTGRES_MAX_CONNECTIONS`, as well as your server’s specs. <!-- Dosu Comment Footer --> *To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/4312456f-b5e3-430e-ad10-f1f5cf6ea69e?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/4312456f-b5e3-430e-ad10-f1f5cf6ea69e?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/4312456f-b5e3-430e-ad10-f1f5cf6ea69e?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/4312456f-b5e3-430e-ad10-f1f5cf6ea69e?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/4312456f-b5e3-430e-ad10-f1f5cf6ea69e?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/4312456f-b5e3-430e-ad10-f1f5cf6ea69e?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/4312456f-b5e3-430e-ad10-f1f5cf6ea69e?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20366)
yindo commented 2026-02-21 19:16:24 -05:00
Author
Owner
Copy Link
Copy Source

@laipz8200 commented on GitHub (Jun 5, 2025):

Dify uses SQLAlchemy's connection pool. By configuring the SQLALCHEMY_POOL_SIZE parameter, the pool will maintain open connections and reuse them for future database operations without releasing them. For configuration options that best suit your needs, please refer to the SQLAlchemy documentation.

@laipz8200 commented on GitHub (Jun 5, 2025): Dify uses SQLAlchemy's connection pool. By configuring the `SQLALCHEMY_POOL_SIZE` parameter, the pool will maintain open connections and reuse them for future database operations without releasing them. For configuration options that best suit your needs, please refer to the [SQLAlchemy documentation](https://docs.sqlalchemy.org).
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#14258
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?