Display Helm Chart Values
helm show values dify/dify
1. Improve Resource Allocation
- You can improve the performance of Dify by adjusting the resource allocation for services in the Helm chart values file.
- You can increase these values based on your environment and available resources.
- Recommended configuration for each component:
| Category | Component | Replicas | Request CPU | Request Mem | Limit CPU | Limit Mem | Notes |
|---|
| Core Application | API | 6 | 1 | 1 GB | 1 | 2 GB | ① |
| Worker | 2 | 4 | 4 GB | 4 | 8 GB | ② |
| Worker Beat | 1 | 1 | 2 GB | 2 | 4 GB | |
| Web | 1 | 0.5 | 1 GB | 1 | 2 GB | |
| Sandbox | 1 | 2 | 2 GB | 2 | 4 GB | ③ |
| Enterprise | Enterprise | 1 | 2 | 2 GB | 2 | 2 GB | |
| Enterprise_Audit | 1 | 1 | 2 GB | 2 | 4 GB | |
| Enterprise_Frontend | 1 | 1 | 2 GB | 1 | 2 GB | |
| Plugin | Plugin Daemon | 1 | 1 | 2 GB | 2 | 4 GB | |
| Plugin Controller | 1 | 0.5 | 1 GB | 1 | 2 GB | |
| Plugin Connector | 1 | 1 | 2 GB | 1 | 2 GB | |
| Plugin Manager | 1 | 1 | 2 GB | 2 | 4 GB | |
| Infrastructure | SSRF Proxy | 1 | 0.5 | 0.5 GB | 1 | 1 GB | |
| Gateway | 1 | 1 | 2 GB | 2 | 4 GB | |
| Unstructured | - | - | - | - | - | As needed |
| MinIO | - | - | - | - | - | As needed |
- ① API: Scale replicas horizontally as needed
- ② Worker: Scale replicas horizontally as needed (if there are many files to upload)
- ③ Sandbox: Scale replicas horizontally as needed (if there are many compute tasks)
maxWorkers: 4 (number of worker processes)workerTimeout: 15 (call timeout)
Configuration Example:
api:
replicas: 6
resources:
requests:
cpu: 1
memory: 1Gi
limits:
cpu: 1
memory: 2Gi
worker:
replicas: 2
resources:
requests:
cpu: 4
memory: 4Gi
limits:
cpu: 4
memory: 8Gi
sandbox:
replicas: 1
maxWorkers: 4
workerTimeout: 15
resources:
requests:
cpu: 2
memory: 2Gi
limits:
cpu: 2
memory: 4Gi
2. Improve External PostgreSQL Performance
2.1 Calculate Database Maximum Connections
When configuring the database, you need to calculate the required maximum connections using the following formula:
Max Connections = (SQLALCHEMY_POOL_SIZE + SQLALCHEMY_MAX_OVERFLOW) × API Workers × API Replicas
+ (SQLALCHEMY_POOL_SIZE + SQLALCHEMY_MAX_OVERFLOW) × Worker Workers × Worker Replicas
SQLALCHEMY_POOL_SIZE: Database connection pool size per workerSQLALCHEMY_MAX_OVERFLOW: Maximum additional connections when pool overflowsAPI Workers: API service’s serverWorkerAmountWorker Workers: Worker service’s celeryWorkerAmount
Calculation Example:
Assuming the following configuration:
- API: replicas=6, serverWorkerAmount=1
- Worker: replicas=2, celeryWorkerAmount=1
- SQLALCHEMY_POOL_SIZE=100
- SQLALCHEMY_MAX_OVERFLOW=150
The maximum connections would be:
(100 + 150) × 1 × 6 + (100 + 150) × 1 × 2 = 1500 + 500 = 2000
It is recommended to reserve 20-30% headroom based on the calculation result to handle traffic spikes. In the above example, set max_connections to 2400-2600.
2.2 Complete Configuration Example
api:
replicas: 6
serverWorkerAmount: 1
extraEnv:
- name: SQLALCHEMY_POOL_SIZE
value: "100"
- name: SQLALCHEMY_MAX_OVERFLOW
value: "150"
resources:
requests:
cpu: 1
memory: 1Gi
limits:
cpu: 1
memory: 2Gi
3.1 Key Metrics
Monitor the following metrics to ensure the system is running well:
Database Connections:
- Current active connections
- Connection pool utilization
- Requests waiting for connections
Resource Usage:
- CPU utilization (recommended to keep below 70%)
- Memory utilization (recommended to keep below 80%)
- Disk I/O
Application Performance:
- API response time
- Worker task queue length
- Task execution time
| Symptom | Possible Cause | Solution |
|---|
| Slow API response | Insufficient API replicas | Increase API replicas |
| Task backlog | Insufficient Worker capacity | Increase Worker replicas or celeryWorkerAmount |
| Database connection exhaustion | Insufficient connections | Increase max_connections or optimize connection pool |
| Out of memory | Memory limit too low | Increase memory limits |
| CPU throttling | CPU limit too low | Increase CPU limits |
