MySQL Governor: Limiting Database Resources for Individual Hosting Customers

What the MySQL Governor Limits

MySQL Governor is a CloudLinux component for shared hosting servers, not a general MySQL feature. It tracks database load based on assigned users and can limit queries via Lightweight Virtual Environments (LVE) when thresholds are exceeded. This allows for a more nuanced view of the load on individual hosting accounts than simply looking at the overall utilization of the database server.

The focus is on CPU and Hard Drive I/O: The Governor monitors computational load as well as read and write activity. High usage can result, for example, from an import or a frequently executed store query. Assigning this usage to an account makes it visible; whether it is appropriate for the specific operation must then be assessed in context.

A database limit for these resources is not a storage quota. A large, infrequently used database may cause little ongoing CPU and I/O load; conversely, a small database can be heavily taxed by many resource-intensive accesses. Connection limits also address a different issue: they restrict access, but do not automatically replace CPU and I/O control.

If a query is throttled, it is not necessarily faulty. The restriction may protect other accounts from high load, but at the same time slow down a legitimate application. This does not guarantee response times, because the database service, hardware, and other application components remain shared parts of the system.

The supplementary overview of the Limiting Database Load with CloudLinux MySQL Governor another entry point. The actual installed environment and the settings in effect there remain crucial for the specific configuration.

Check Edition and Compatibility

Before planning the database limits, you should first check Edition and License. According to the manufacturer, CloudLinux OS Admin does not include MySQL Governor. Therefore, the presence of a CloudLinux system alone does not prove that the component is available, licensed, and installed on the server for the selected edition.

Next, consider the combination of CloudLinux version, Governor package, and database server. MySQL and MariaDB are separate development branches: A supported MySQL version does not guarantee that a MariaDB version of the same age will work under the same conditions. The control panel used and its integration should also be evaluated.

The minimum requirements show why a blanket approval is not sufficient: For MySQL 8.4, CloudLinux specifies a minimum of MySQL Governor 1.2-129. MariaDB 11.4 requires at least version 1.2-122 of the Governor and is not supported for CloudLinux OS 7 in the vendor’s documentation. These specifications apply to the branches mentioned and do not replace verification of the remaining combinations.

The manufacturer lists cPanel, Plesk, DirectAdmin, ISPmanager, and InterWorx, among others, as supported installation environments, as well as servers without a control panel. If you’re using a different control panel or one you’ve integrated yourself, you should clarify the specific support—and, in particular, user assignment—separately. A listed database version does not guarantee compatibility with every combination of control panel and operating system.

Before making any changes, note the existing versions and packages and compare them with the documentation for the planned target configuration. This will help you determine whether you need to replace any components first, rather than assuming an existing installation is compatible based solely on the database name.

Assign Database Users to Hosting Accounts

In order for the load to be assigned to a hosting customer, the connection between database users and hosting accounts must be correct. With a control panel integration, the file /etc/container/dbuser-map maintained. The Governor applies changes to this mapping within five minutes, as specified in the integration documentation.

Here’s an example: A hosting account runs a store and a separate blog, each of which uses its own database user. If both users are assigned to the same account, the database load can be tracked for that account. If one of the entries is missing or points to the wrong account, the displayed assignment is not reliable for customer-specific evaluation.

Check the User Assignment Therefore, this isn't limited to the initial installation. Even after creating or moving databases and users, the panel must correctly update the assignments. When checking immediately after a change, take the documented synchronization period into account before concluding that a persistent error exists based on outdated data.

A lack of mapping in Abusers mode is particularly important: According to the manufacturer, this mode emulates Single mode. Restricted clients share a common restricted LVE in Single mode, rather than being limited to their own client LVE. Therefore, an activated “Abusers” mode alone does not prove that the intended account-specific restriction is actually in effect.

If any anomalies are detected, compare the affected database users, the maintained mapping, and the selected operating mode. Even correct mapping does not guarantee complete isolation: The database service and the underlying hardware continue to be shared. The mapping is a prerequisite for customer-specific control, not a substitute for capacity planning.

Comparison of Operating Modes

The operating mode determines whether MySQL Governor merely monitors database load or executes queries in a restricted environment. The choice is not determined by thresholds alone: The assignment of database users and the question of which clients share an LVE also influence the outcome.

A good way to take stock is Off Note: The observed usage shows which accounts and time periods warrant closer scrutiny, without the Governor throttling queries in the process. However, a single high instantaneous value does not necessarily indicate whether an account is consistently generating a high load or is simply performing legitimate maintenance work.

At Abusers Restricted database queries share the LVE resource budget with other processes under the same account, such as PHP. A restriction can therefore not only prolong queries: the application may also respond more slowly if its processes are competing for the same limited resources. Conversely, PHP resources that are already in use can affect database performance.

"Single" is deprecated and is primarily relevant for existing configurations and the documented fallback behavior: Multiple restricted clients share an environment and can compete with one another within it. If the `dbuser-map` is missing, `Abusers` emulates this behavior; the selected setting alone does not indicate a client-specific restriction. "All" is also deprecated and is not a standard recommendation for a new installation.

Planning Database Limits and Time Windows

MySQL Governor distinguishes between CPU usage and read and write I/O. The documented CLI displays CPU usage as a percentage and I/O as MB/s; separate values can be configured for reads and writes. These metrics describe different types of load: A computationally intensive operation does not necessarily involve a particularly high volume of writes to the storage device.

The Thresholds current, short, medium, and long These values account for both short-term and longer-term usage. Exceeding them triggers a restriction, depending on the operating mode and configuration. They are neither guaranteed throughput nor four independent, permanently and strictly enforced performance commitments. Which restriction actually takes effect also depends on the selected method and the LVE limits.

An import illustrates the difference: If the write load spikes briefly and then drops again, it may be part of a scheduled operation. If it remains high for an extended period, the import will consume resources for longer. When making a decision, in addition to the peak value, you should check which resource is affected, how long the process takes, and whether it repeats.

Low Trigger thresholds They can protect other customers from sustained load earlier, but may also slow down legitimate imports or maintenance jobs. High thresholds allow more leeway for such work, but at the same time permit a higher load for a longer period. A maintenance window or a specifically planned capacity may be more appropriate than a permanent exception.

Plan the governor values in relation to the LVE limits and the rates actually offered. The manufacturer’s recommendations explicitly take this relationship into account; however, universally applicable production values cannot be derived from them. Observed request load, query efficiency, and the nature of customer workloads provide the basis for making controlled adjustments to thresholds after implementation.

Prepare for the launch and set rate limits

Before installing or upgrading, there is a Complete database backup including the system tables. Also plan how the system will be restored if necessary. The vendor notes that database packages can be updated from CloudLinux repositories; therefore, changing packages is not a trivial side effect that you should only check after installation.

Next, verify the combination of CloudLinux edition and version, license, database branch, Governor package, and control panel. A supported database version alone does not guarantee that every combination of these components is supported. If package versions or panel integration are not compatible, you must confirm specific support before making any changes.

After completing the technical preparations, start by monitoring the system rather than immediately throttling it. Compare typical business hours with known import and maintenance windows, and check whether database users are assigned to the correct hosting accounts. Without reliable assignment, an apparently low account load does not allow for a reliable conclusion about actual resource requirements.

Based on this assessment, develop a limited rollout plan: Determine which accounts or rate plans should be affected, how complaints will be recorded, and what metrics you will use to evaluate the implementation. After activation, compare any deviations against standard operating procedures rather than immediately treating every deviation as a violation.

CloudLinux Manager can manage governor limits on a per-packet basis; different values may apply for individual customers. Therefore, document the Origin of the Limit: Is it part of the package or set individually? This makes it possible to determine later which customers are affected by a rate change and which exceptions need to be reviewed separately.

Check Current Load and History

To make a diagnosis, you'll need both a Snapshot as well as the timeline. The following commands are executed in the CloudLinux server's terminal, not in the MySQL console. They are for informational purposes only and do not change any limits; for a meaningful analysis, the respective tools must be installed and the relevant data must be available.

Identify suspicious accounts with the User Assignment and the selected operating mode. If a database user is missing from the mapping, the visible load for the hosting account may be incomplete. The integration documentation states that changes to the mapping file take effect within five minutes; therefore, an output checked immediately afterward may not yet reflect the new status.

Next, compare the time of a restriction with the observed usage pattern. A high individual value may be part of an import and, on its own, is not evidence of sustained excessive use. The Guide to Reading MySQL Governor Reports supplements the classification of the displayed key figures.

Distinguishing Between Throttling and Its Causes

If a website slows down, first check whether any restrictions were active at that time and what reason is displayed. Relate this finding to the specific event: A slow checkout and an import running at the same time may be related, but they may not be. Without a temporal overlap, it would be premature to conclude that the governor is the sole cause.

In Abusers mode, limited database queries are executed in the LVE of the assigned account. There, they share the Resource budget with other account processes, such as PHP. Therefore, when a complaint arises, consider both sides: A database-intensive task may compete with PHP for resources; conversely, LVE capacity that is already in use may affect the limited queries.

If the load issue recurs with a shop feature, investigate the relevant query and its Query Plan along with appropriate database statistics. A missing or inappropriate index is a possible cause, but not the only one. The limit can reduce the impact on shared resources; it does not correct either the plan or the application logic.

For "Single" and "Abusers," CloudLinux states that restrictions are lifted once usage has been below the threshold for one minute. However, you should verify the actual Restrict configuration and the timeline on your own system, rather than jumping to the conclusion that a brief relief in usage indicates a permanent solution. A task that restarts may later exceed a threshold again.

Readjust limits or change the architecture

Start the adjustment process by asking whether the observed spike is part of an expected task or regularly disrupts operations. A scheduled import may be able to be rescheduled to a maintenance window. Be sure to record the duration, the affected resource, and the impact on the application before concluding that a single spike warrants a permanent rate change.

If the time frame is not sufficient, a targeted Wage Exemption This may be more appropriate than a blanket increase for all customers. Document the reason, the contact person responsible, and the date of the review. Also note whether the current value is based on the package or was set individually: CloudLinux Manager supports package-based limits and custom exceptions.

After making a change, monitor the system over a representative period of time to see if the intended workload is processing more efficiently and if any bottlenecks or issues arise elsewhere. When doing so, compare the governor thresholds to the LVE limits. A higher threshold potentially allows for a greater load over a longer period; it is neither a guaranteed throughput nor a commitment to specific response times.

Another factor to consider is the Troubleshooting: Query optimization, appropriate indexes, or caching can reduce recurring workloads rather than merely limiting their impact. Database-level connection limits, on the other hand, restrict concurrent access and do not automatically replace the governor's CPU and I/O control.

If a customer’s requirements differ significantly from those of shared hosting on a long-term basis, it may make sense to use a dedicated database instance or server. However, this shifts the decision from individual thresholds to planning for capacity, maintenance, and operations. Even such a separation should not be presented as a blanket guarantee of complete isolation or fixed response times.