DHIS2 performance problems usually fall into one of three buckets: the application is starved of resources, the database is misconfigured, or analytics maintenance is overdue.
1. Watch the basics first
Check CPU, memory and swap before touching DHIS2 configuration. A server that is swapping is slow no matter what the application settings say.
top
free -h
sar -q
2. PostgreSQL settings that matter
DHIS2 ships with baseline tuning, but shared buffers and work memory are still the most common pain points on medium instances.
shared_buffers = 4GB
work_mem = 64MB
maintenance_work_mem = 1GB
effective_cache_size = 12GB
Rule of thumb: shared_buffers around 25 percent of RAM and effective_cache_size around 75 percent. Test after every change with a representative workload.
3. Analytics tables grow out of control
If resource tables and analytics tables are large, run the analytics maintenance jobs during a quiet window and keep the schedule regular.
- Run analytics tables update weekly, not on demand.
- Vacuum and analyze the database between runs.
- Archive old events before the tables become unmanageable.
4. Quick wins checklist
| Issue | Check | Typical fix |
|---|---|---|
| Slow login and dashboard load | CPU usage | Add cores or trim heavy jobs |
| Analytics run takes hours | Table bloat | Vacuum, then rebuild indexes |
| Timeouts from the app server | Memory pressure | Raise heap and restart Tomcat |
| Disk filling up | Log rotation | Rotate catalina and DHIS2 logs |
Always reproduce the slow scenario before and after each change so you can measure whether a fix actually helped.
Comments 0
No comments yet — be the first to share your thoughts.
Leave a comment
Comments are moderated and appear after approval.