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

Postgres connections spike and are not released / not reused under high concurrency (Dify 1.8.1, K8s) #19072

New Issue
Closed
opened 2026-02-21 19:55:22 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 19:55:22 -05:00
Owner
Copy Link
Copy Source

Originally created by @weyuhui110 on GitHub (Oct 11, 2025).

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.8.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

100 concurrent pressure test dialogue interfaces with 10 API pods

✔️ Expected Behavior

Correctly releasing database links and reusing database connections

❌ Actual Behavior

Body
Environment

  • Dify version: 1.8.1
  • Deployment: Kubernetes
  • Config location: dify-api ConfigMap

What I configured

  • SQLALCHEMY_POOL_SIZE = 50
  • SQLALCHEMY_POOL_RECYCLE = 300 (seconds)

What I did
I ran a high-concurrency test (about 100 concurrent requests) against the Dify conversation API endpoint.

Observed behavior

  • Postgres connection count spikes during the test.
  • The connections are not reused — instead the number of connections grows.
  • After the spike the connections remain and become idle; they are not released back to the database.
  • This happens even though I set SQLALCHEMY_POOL_RECYCLE = 300. My understanding is that the pool should reuse connections and that idle connections would be recycled/released after 300 seconds.

Expected behavior

  • Under high concurrency, connections should be reused up to the configured pool size.
  • Idle connections should be properly handled/recycled according to SQLALCHEMY_POOL_RECYCLE (i.e., not accumulate indefinitely).

Additional notes / questions

  • The configuration is placed in the dify-api ConfigMap — is that the correct service to configure for SQLAlchemy pool settings, or should these settings be applied to another component?
  • Is this a known issue in v1.8.1, or am I missing some config or runtime setting for K8s deployment that affects connection pooling?

If you need logs, metrics, or a minimal reproduction (k8s manifests / test script), I can provide them. Thank you!

Originally created by @weyuhui110 on GitHub (Oct 11, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.8.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 100 concurrent pressure test dialogue interfaces with 10 API pods ### ✔️ Expected Behavior Correctly releasing database links and reusing database connections ### ❌ Actual Behavior **Body** **Environment** * Dify version: `1.8.1` * Deployment: Kubernetes * Config location: `dify-api` ConfigMap **What I configured** * `SQLALCHEMY_POOL_SIZE = 50` * `SQLALCHEMY_POOL_RECYCLE = 300` (seconds) **What I did** I ran a high-concurrency test (about 100 concurrent requests) against the Dify conversation API endpoint. **Observed behavior** * Postgres connection count spikes during the test. * The connections are not reused — instead the number of connections grows. * After the spike the connections remain and become idle; they are not released back to the database. * This happens even though I set `SQLALCHEMY_POOL_RECYCLE = 300`. My understanding is that the pool should reuse connections and that idle connections would be recycled/released after 300 seconds. **Expected behavior** * Under high concurrency, connections should be reused up to the configured pool size. * Idle connections should be properly handled/recycled according to `SQLALCHEMY_POOL_RECYCLE` (i.e., not accumulate indefinitely). **Additional notes / questions** * The configuration is placed in the `dify-api` ConfigMap — is that the correct service to configure for SQLAlchemy pool settings, or should these settings be applied to another component? * Is this a known issue in v1.8.1, or am I missing some config or runtime setting for K8s deployment that affects connection pooling? If you need logs, metrics, or a minimal reproduction (k8s manifests / test script), I can provide them. Thank you!
yindo added the 🐞 bug label 2026-02-21 19:55:22 -05:00
yindo closed this issue 2026-02-21 19:55:22 -05:00
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#19072
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?