LVE limits contain a user's PHP, cron and shell processes, but MySQL runs as one mysql process outside every LVE. A single unindexed query from one customer's shop can put a whole core of mysqld to work for minutes, and lveinfo shows nothing for that user because the work is being done on their behalf by a process they do not own. MySQL Governor is CloudLinux's fix: it accounts database load per user and, when someone goes over the line, makes their queries run inside their own LVE so their limits apply to the database too.
How it works
CloudLinux's build of MariaDB and MySQL carries a userstat patch that records CPU time and disk reads and writes per database user. The governor maps database users to system users through the panel's prefix convention, bob_shop belongs to bob, and keeps four rolling averages for each: over 1 second, 5 seconds, 1 minute and 5 minutes. A short burst is allowed to be high; sustained load is held lower.
What happens when a user exceeds a limit depends on the mode in /etc/container/mysql-governor.xml. In abusers, the default, only users over their limits are restricted: their queries are moved into their LVE, where the SPEED and IO limits throttle them. In all, every user's queries always run inside their LVE, which is the fairest setting and the one to aim for once you trust the limits. There is also a monitoring-only setting that records usage without acting, which is a good way to spend the first week.
Note what restriction is not: nobody is disconnected and no query is killed. The heavy user gets slower; everyone else gets their server back.
Installing it on DirectAdmin
The governor needs CloudLinux's own database build, so the installer replaces the MariaDB packages with the matching version. That means a MySQL restart and a minute or two of downtime, so take a backup first and do it in a quiet window:
yum install governor-mysql
/usr/share/lve/dbgovernor/mysqlgovernor.py --mysql-version=mariadb1011
/usr/share/lve/dbgovernor/mysqlgovernor.py --installPick a --mysql-version that matches what CustomBuild installed, or the version you intend to move to; the installer lists what it supports if you give it an unknown name. DirectAdmin and cPanel are both supported for the automatic install. On Plesk the steps are manual and documented on docs.cloudlinux.com. Afterwards mysql -V shows a CloudLinux build string, and systemctl status db_governor shows the service running.
Data files stay where they were and the panel's mysql.conf credentials keep working. CustomBuild should not be used to rebuild MariaDB from this point, because it would swap the governed build back out.
Watching who is heavy
dbtop is the live view: one line per user with CPU as a percentage of a core and read and write throughput, each across the four windows, updating every second. Sort by CPU and the heavy account is at the top within seconds of a complaint arriving. For the state without the animation:
dbctl list
dbctl list-restricteddbctl list prints every user's limits; dbctl list-restricted shows who is currently held inside their LVE and since when. CloudLinux Manager carries the same MySQL columns in its user list, which is how you spot the pattern of one user restricted every evening at the same time.
Setting limits
Limits are per user or as the default everyone inherits, with four values for the four windows:
dbctl set default --cpu=150,100,70,50
dbctl set bob --cpu=200,150,100,80 --read=2048,1500,1000,800 --write=2048,1500,1000,800CPU is a percentage of one core: the default above lets an account burst to 150% for a second but averages no more than 50% over five minutes. The read and write columns are disk throughput; check the units dbctl list prints on your build before copying numbers across servers. Values scale like LVE limits do, with a bigger package getting a bigger allowance, and the defaults are wide enough that a normal WordPress site never touches them.
You can also intervene by hand while you investigate:
dbctl restrict bob
dbctl unrestrict bob
dbctl unrestrict-allFinding the actual cause
The governor tells you who; it does not tell you what. Once dbtop names the user, log in to MariaDB and look at what they are running:
mysql -e "SHOW FULL PROCESSLIST" | grep bob_Nine times out of ten it is a WordPress plugin querying wp_options or wp_postmeta without an index, a search page being hammered by a bot, or an abandoned cart table with a million rows and a nightly report across all of them. The site owner fixes those; the governor's job is to keep them from being your problem in the meantime. Enable the slow query log for the case where a single statement is responsible, and use the advice in MySQL and MariaDB tuning basics for the server-wide side: a governor cannot rescue a server whose buffer pool is too small for everyone.
Where it fits with the rest
MySQL Governor closes the last gap in per-user isolation. With LVE limiting PHP, CageFS isolating files and the governor accounting for the database, a heavy customer on a shared server slows down their own site and nothing else, which is the whole promise of CloudLinux. Reading the combined picture, including the MySQL columns next to CPU and memory faults, is covered in how to read LVE statistics. When a user is restricted every day and their queries are already sensible, they need a bigger database than shared hosting gives, and that conversation is easier with a week of dbctl history behind it.