Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11.7
-
None
-
None
-
CloudLinux release 7.9
Description
Hello,
Recently, we've noticed that there are cases where one database user can manage to completely overload the MariaDB server by what appears like bypassing fairly strict max_user_connections during high server load scenarios when an application using MariaDB as SQL backend such as a spike in traffic or receiving a DDoS attack.
For example, in this case, the DB user has two hosts: `127.0.0.1` and `localhost`. Both have a limit set to 25.
MariaDB [mysql]> select user, max_user_connections from user where user = 'user_kaBhv'; |
+------------------+----------------------+
|
| User | max_user_connections |
|
+------------------+----------------------+
|
| user_kaBhv | 25 | |
| user_kaBhv | 25 | |
+------------------+----------------------+
|
2 rows in set (0.008 sec) |
But during DDoS, there were `110` queries in the `QUERY` state when checking the process list:
select user, count(user) from information_schema.processlist group by user order by count(user);
|
+---------------------------+-------------+
|
| user | count(user) |
|
+---------------------------+-------------+
|
| u_8Cqh6 | 23 | |
| u_kaBhv | 110 | |
+---------------------------+-------------+
|
This one above is one of the milder examples; there were numerous situations where it would be over 10 times the limit on other servers and users:
select user, count(user) from information_schema.processlist group by user order by count(user);
|
+---------------------------+-------------+
|
| user | count(user) |
|
+---------------------------+-------------+
|
...
|
| user_riek | 263 | |
select user, max_user_connections from mysql.user where user = 'user_riek'; |
 |
+--------------------+----------------------+
|
| User | max_user_connections |
|
+--------------------+----------------------+
|
| user_riek | 35 | |
| user_riek | 35 | |
| user_riek | 35 | |
+--------------------+----------------------+
|
3 rows in set (49.045 sec) |
If you need any other information, please let us know.