Avoid Common Druid Connection Pool Pitfalls: Key Configurations Explained

Introduction

Database connection pools are widely used for their reuse benefits, but they introduce a set of parameters that must be understood to avoid hidden pitfalls. Using Druid 1.1.5 as an example, the article explains the most critical settings and how to troubleshoot common problems.

1. Connection Pool Configuration

1.1 maxWait

maxWait defines the timeout (in milliseconds) for obtaining a connection from the pool. A value of 0 means unlimited waiting, which can cause request queues to grow indefinitely under load.

Recommended setting: 800 ms on a stable internal network; ≥1200 ms when the network is less reliable.

Case 1 – High traffic with maxWait=0 and maxActive=5 caused the pool to exhaust, leading to massive request time‑outs.

maxWait=0,
maxActive=5,
…

Case 2 – Two data sources deadlocked; removeAbandoned=true and removeAbandonedTimeout=180 marked connections as abandoned after 180 s. Setting maxWait=3000 (3 s) resolved the MQ backlog.

maxWait=0,
removeAbandoned=true,
removeAbandonedTimeout=180,
…

1.2 connectionProperties

These key‑value pairs allow configuring connectTimeout and socketTimeout (both in ms). They are crucial for handling network anomalies; if omitted, dead connections may block the pool.

Recommended setting:

socketTimeout=3000;connectTimeout=1200

1.3 keepAlive

keepAlive determines whether idle connections are kept alive. The default in Druid 1.0.28+ is false. Enabling it without proper auxiliary settings can still fail.

Recommended setting: true when the network is unstable or traffic spikes are frequent.

Case 1 – Configuration with equal minEvictableIdleTimeMillis and maxEvictableIdleTimeMillis caused immediate eviction, so keep‑alive never succeeded.

keepAlive=true,
minIdle=5,
timeBetweenEvictionRunsMillis=10000,
minEvictableIdleTimeMillis=100000,
maxEvictableIdleTimeMillis=100000,
…

Case 2 – Slightly lower minEvictableIdleTimeMillis created a timing window where the eviction thread might miss the check, making keep‑alive behavior nondeterministic.

keepAlive=true,
minIdle=5,
timeBetweenEvictionRunsMillis=10000,
minEvictableIdleTimeMillis=95000,
maxEvictableIdleTimeMillis=100000,
…

1.4 maxActive

maxActive limits the maximum number of simultaneous connections. Setting it too high can degrade throughput, especially under lock‑contention scenarios such as flash‑sale spikes.

Recommended setting: 20 (generally 3–5× the normal connection count).

2. Investigating “Slow Queries”

Even with proper configuration, “slow query” symptoms may arise from other layers. The article walks through a real incident where DB logs showed no slow queries, but the actual bottleneck was a synchronous logging operation that stalled the request path. Using strace to trace the SQL execution revealed the hidden delay, and fixing the logging issue eliminated the slow‑query alarms.

Conclusion

Effective DB connection‑pool management requires understanding each parameter’s impact, applying sensible defaults, and being prepared to diagnose issues that surface beyond the database itself. The shared cases and troubleshooting steps aim to help engineers avoid common traps and maintain stable, high‑performance services.