“Too Many Connections” Is Never a Surprise — Until It Is
MySQL has a hard ceiling on connections. When you hit it, new connection attempts are rejected immediately with:
ERROR 1040 (HY000): Too many connectionsThe problem is that by the time you see that error, you are already past the limit. The application is failing. The on-call phone is ringing.
This script lets you check where you are before that happens.
Loading…
Reading the Results
Query 1 — Snapshot
| Column | What It Tells You |
|---|---|
max_connections | The hard ceiling configured on this server |
current_connections | How many connections are open right now |
peak_connections | The highest concurrent count since the server started |
pct_used | If this is above 80%, review your connection pooling |
If peak_connections is within 20% of max_connections, you have been close to the limit at some point.
Query 4 — Sleep Accumulation
Sleeping connections are not free — they still hold a slot against max_connections. Applications that do not close connections properly will accumulate hundreds of sleepers. A high longest_sleep_seconds means connections are being left open far too long.
Query 5 — Variables
| Variable | What It Controls |
|---|---|
wait_timeout | How long to keep an idle non-interactive connection |
interactive_timeout | Same, for interactive sessions (MySQL clients) |
thread_cache_size | Cached threads to reuse — reduces new connection overhead |
max_user_connections | Per-user connection cap (0 = no per-user limit) |
What to Watch For
| Signal | What It Means |
|---|---|
pct_used > 80% | You are close — review connection pooling configuration |
peak_connections near max_connections | You have hit close to the ceiling historically |
| Large sleeping connection count | Application not closing connections; reduce wait_timeout |
| One user dominating the connection list | Connection pool misconfigured or app server count too high |
max_connections very high (e.g. 5000+) | Memory pressure risk — each connection uses ~1MB RAM |
Gareth Winterman