How a single MySQL connection issue took down rupal Site, my learnings and how I approached it.

I recently faced an issue stating the error:

PDOException: SQLSTATE[42000] [1203] User drupal_project_mm already has more than 'max_user_connections' active connections in lock_may_be_available() (line 167 of /home/project/public_html/includes/lock.inc).

That message isn’t random, it means MySQL refused new database connections because too many of them were already open under that user. Here’s exactly what I did to diagnose and fix it, step by step.

Quick summary of the real problem

• Drupal opens database connections for requests.
• Some connections were left idle (“Sleep”) and piled up.
• The database (a shared Hostinger server) enforces connection limits. Once the limit was reached, new connections were rejected and Drupal stopped working.
• The error happened during Drupal’s early bootstrap (in lock_may_be_available()), so the site couldn’t even acquire DB locks or serve pages.

Solution:

I looked at the active DB threads

SHOW FULL PROCESSLIST;

This shows every current MySQL thread (Query, Sleep, etc.). I found idle “Sleep” entries for my DB user, sessions that were using slots but doing nothing.

I ran

SELECT CONCAT('KILL ', ID, ';') AS cmd
FROM information_schema.processlist
WHERE USER = 'mindmoti' AND COMMAND = 'Sleep' AND ID <> CONNECTION_ID();

In simple terms, this query looked inside MySQL’s internal process list , a table that shows every active database connection , and finds all the idle (“sleeping”) connections belonging to the user mindmoti. It then builds a list of KILL commands for each of those inactive sessions, excluding the one currently running the query (ID <> CONNECTION_ID()).

These “sleeping” connections were taking up MySQL connection slots, triggering the “already has more than ‘max_user_connections’” error and bringing the Drupal site down. By running this command and executing the generated KILL statements, all those unused connections were terminated, freeing up resources and immediately allowing Drupal to reconnect to the database , bringing the site back online…

Note:

• You can only kill threads owned by your user — you won’t be able to kill other accounts’ sessions.
• After killing sleep rows, clear caches and consider restarting PHP to fully reset connections.