MySQL Governor: limitar los recursos de la base de datos de cada cliente de alojamiento

Lo que limita MySQL Governor

MySQL Governor Es un componente de CloudLinux para servidores de alojamiento compartido, no una función general de MySQL. Mide la carga de la base de datos en función de los usuarios asignados y, si se superan los umbrales establecidos, puede limitar las consultas mediante los «Lightweight Virtual Environments» (LVE, por sus siglas en inglés). De este modo, se puede analizar la carga de cada cuenta de alojamiento de forma más diferenciada que si solo se tuviera en cuenta la carga total del servidor de bases de datos.

Lo más destacado es CPU y E/S del disco duro: El Governor tiene en cuenta la carga de cálculo, así como la actividad de lectura y escritura. Un uso elevado puede deberse, por ejemplo, a una importación o a una consulta de la tienda que se realiza con frecuencia. La asignación a una cuenta hace visible este uso; a continuación, hay que evaluar en su contexto si es adecuado para la operación en cuestión.

Un límite de base de datos para estos recursos no es una cuota de espacio de almacenamiento. Una base de datos grande que se utiliza con poca frecuencia puede generar poca carga de CPU y de E/S; por el contrario, una base de datos pequeña puede verse sometida a una gran carga debido a numerosos accesos que requieren muchos recursos. Los límites de conexiones también responden a otra cuestión: limitan los accesos, pero no sustituyen automáticamente el control de la CPU y las E/S.

El hecho de que una consulta se vea limitada no significa necesariamente que sea errónea. La restricción puede proteger a otras cuentas de una carga elevada, pero al mismo tiempo ralentizar una aplicación legítima. Esto no garantiza unos tiempos de respuesta fijos, ya que el servicio de base de datos, el hardware y otros componentes de la aplicación siguen siendo partes compartidas del sistema.

Para comprender la interacción entre las cuentas, los cargos y las partidas contables, la visión general complementaria sobre la Limitación de la carga de la base de datos con CloudLinux MySQL Governor una opción adicional. El entorno realmente instalado y la configuración vigente en él siguen siendo determinantes para la configuración concreta.

Comprobar la edición y la compatibilidad

Antes de planificar los límites de la base de datos, comprueba primero Edición y licencia. Según el fabricante, CloudLinux OS Admin no incluye MySQL Governor. Por lo tanto, el mero hecho de disponer de un sistema CloudLinux no garantiza que dicho componente esté disponible, que cuente con la licencia correspondiente y que esté instalado en el servidor para la edición elegida.

A continuación, debes tener en cuenta la combinación de la versión de CloudLinux, el paquete Governor y el servidor de bases de datos. MySQL y MariaDB son ramas de desarrollo independientes: el hecho de que una versión de MySQL sea compatible no garantiza que una versión de MariaDB de la misma antigüedad funcione en las mismas condiciones. También hay que tener en cuenta el panel de control utilizado y su integración.

Los requisitos mínimos demuestran por qué no basta con una autorización general: para MySQL 8.4, CloudLinux exige como mínimo la versión 1.2-129 de MySQL Governor. MariaDB 11.4 requiere como mínimo la versión 1.2-122 del Governor y, según la documentación del fabricante, no es compatible con CloudLinux OS 7. Estos datos se refieren a las ramas mencionadas y no sustituyen a la comprobación del resto de combinaciones.

Entre los entornos de instalación, el fabricante menciona, entre otros, cPanel, Plesk, DirectAdmin, ISPmanager e InterWorx, así como servidores sin panel de control. Si se utiliza un panel diferente o uno integrado por ti mismo, debes aclarar por separado la compatibilidad concreta y, sobre todo, la asignación de usuarios. El hecho de que se indique una versión de base de datos no garantiza su compatibilidad con todas las combinaciones de paneles y sistemas operativos.

Anota las versiones y los paquetes actuales antes de realizar cualquier cambio y compáralos con la documentación de la configuración de destino prevista. De este modo, podrás determinar si sería necesario cambiar algún componente, en lugar de dar por hecho que una instalación existente es compatible basándote únicamente en el nombre de la base de datos.

Asignar cuentas de alojamiento a usuarios de la base de datos

Para que la carga se pueda asignar a un cliente de alojamiento web, la relación entre los usuarios de la base de datos y las cuentas de alojamiento debe ser correcta. En el caso de una integración con el panel de control, para ello se suele utilizar el archivo /etc/container/dbuser-map actualizada. El Governor aplica los cambios en esta asignación, según la documentación de integración, en un plazo de cinco minutos.

Un ejemplo: una cuenta de alojamiento aloja una tienda y un blog independiente, cada uno de los cuales funciona con su propio usuario de base de datos. Si ambos usuarios están asignados a la misma cuenta, la carga de la base de datos se puede registrar en función de dicha cuenta. Si falta alguna de las entradas o si esta apunta a una cuenta incorrecta, la asignación mostrada no es fiable para una evaluación relacionada con el cliente.

Comprueba la Asignación de usuarios Por eso, no solo durante la instalación inicial. Incluso después de crear o mover bases de datos y usuarios, el panel debe actualizar correctamente la asignación. Si realizas una comprobación inmediatamente después de un cambio, debes tener en cuenta el plazo de actualización documentado antes de concluir que se trata de un error permanente basándote en una versión aún obsoleta.

Es especialmente importante la ausencia de asignación en el modo «Abusers»: según el fabricante, este modo emula entonces el modo «Single». Los clientes con restricciones comparten en el modo «Single» un LVE común y restringido, en lugar de estar limitados cada uno en su propio LVE de cliente. Por lo tanto, el mero hecho de que el modo «Abusers» esté activado no garantiza por sí solo que la restricción prevista para cada cuenta se aplique realmente.

En caso de anomalías, compara entre sí los usuarios de la base de datos afectados, la asignación configurada y el modo de funcionamiento seleccionado. Ni siquiera una asignación correcta garantiza un aislamiento total: el servicio de base de datos y el hardware subyacente siguen compartiéndose. La asignación es un requisito previo para el control específico por cliente, no un sustituto de la planificación de la capacidad.

Comparación de los modos de funcionamiento

El modo de funcionamiento determina si MySQL Governor se limita a supervisar la carga de la base de datos o si ejecuta consultas en un entorno limitado. Para tomar esta decisión, no solo son importantes los umbrales: la asignación de los usuarios de la base de datos y el hecho de qué clientes comparten una LVE también influyen en el resultado.

Para hacer un balance, lo más adecuado es Fuera de Nota: El uso observado indica qué cuentas y en qué periodos merecen un análisis más detallado, sin que el Governor limite las consultas. Sin embargo, un único valor puntual elevado no indica por sí solo si una cuenta genera una carga elevada de forma permanente o si simplemente está realizando una tarea de mantenimiento legítima.

En Abusadores Las consultas a la base de datos con restricciones comparten el presupuesto de recursos de LVE con otros procesos de la misma cuenta, como PHP. Por lo tanto, una restricción no solo puede alargar la duración de las consultas: la aplicación también puede responder con más lentitud si sus procesos compiten por los mismos recursos limitados. A la inversa, el presupuesto de PHP ya ocupado puede afectar al funcionamiento de la base de datos.

La opción «Single» está obsoleta y es relevante sobre todo para configuraciones existentes, así como para el comportamiento de sustitución documentado: varios clientes con restricciones comparten un entorno y pueden competir entre sí en él. Si no existe el archivo «dbuser-map», «Abusers» emula este comportamiento; por lo tanto, la configuración seleccionada por sí sola no permite deducir que exista una restricción propia del cliente. La opción «All» también está obsoleta y no se recomienda para una nueva instalación.

Planificar los límites de la base de datos y las franjas horarias

MySQL Governor distingue entre el uso de la CPU y las operaciones de E/S de lectura y escritura. La CLI documentada muestra el uso de la CPU en porcentaje y la E/S en MB/s; se pueden configurar valores distintos para la lectura y la escritura. Estas magnitudes describen cargas diferentes: una operación que requiere un gran esfuerzo de cálculo no tiene por qué implicar, al mismo tiempo, una gran cantidad de escritura en el soporte de datos.

Los umbrales corte, corto, medio y largo Tienen en cuenta el uso a corto plazo y el uso prolongado. Su superación activa una restricción, dependiendo del modo de funcionamiento y la configuración. No se trata ni de un caudal garantizado ni de cuatro compromisos de rendimiento independientes entre sí que se apliquen de forma permanente y estricta. La restricción que se aplique realmente depende también del procedimiento seleccionado y de los límites de LVE.

Una importación ilustra bien la diferencia: si la carga de escritura aumenta brevemente y luego vuelve a descender, puede formar parte de una operación planificada. Si se mantiene alta durante un tiempo prolongado, la importación consume recursos durante más tiempo. Para tomar una decisión, además del valor máximo, debes comprobar qué recurso se ve afectado, cuánto tiempo dura el proceso y si se repite.

Bajo Umbrales de activación pueden proteger a otros clientes de una carga prolongada, pero también pueden ralentizar importaciones o tareas de mantenimiento legítimas. Los umbrales altos dejan más margen para este tipo de trabajos, pero al mismo tiempo permiten una carga más elevada durante más tiempo. Una ventana de mantenimiento o una capacidad planificada específicamente puede resultar más adecuada que una excepción permanente.

Planifica los valores del regulador en relación con los límites de LVE y con las tarifas realmente ofrecidas. Las recomendaciones del fabricante tienen en cuenta expresamente esta relación; sin embargo, de ellas no se pueden deducir valores de producción de carácter general. La carga de solicitudes observada, la eficiencia de las consultas y el tipo de trabajos de los clientes constituyen la base para ajustar los umbrales de forma controlada tras la implantación.

Preparar la puesta en marcha y los límites tarifarios

Antes de la instalación o la actualización hay que copia de seguridad completa de la base de datos incluidas las tablas del sistema. Planifica también cómo se llevará a cabo la restauración en caso de que sea necesario. El fabricante señala que los paquetes de la base de datos se pueden actualizar desde los repositorios de CloudLinux; por lo tanto, cambiar de paquete no es un efecto secundario sin consecuencias que debas comprobar solo después de la instalación.

A continuación, comprueba la combinación de edición y versión de CloudLinux, licencia, rama de la base de datos, paquete Governor y panel de control. El hecho de que una versión de la base de datos sea compatible no garantiza por sí solo que se admita cualquier combinación de estos componentes. Si las versiones de los paquetes o la integración del panel no coinciden, es necesario aclarar la compatibilidad concreta antes de realizar cualquier intervención.

Tras la preparación técnica, empieza por observar en lugar de limitar el tráfico de inmediato. Compara los horarios habituales de trabajo con las ventanas de importación y mantenimiento conocidas y comprueba si los usuarios de la base de datos están asignados a las cuentas de alojamiento correctas. Sin una asignación fiable, no se puede deducir con certeza la necesidad real de recursos a partir de una carga de cuentas aparentemente baja.

A partir de este análisis de la situación, elabora una implementación limitada: determina qué cuentas o tarifas deben verse afectadas, cómo se registrarán las reclamaciones y en función de qué observaciones comprobarás la configuración. Tras la activación, compara las restricciones con los procesos de uso, en lugar de considerar cada incumplimiento como una conducta indebida de inmediato.

CloudLinux Manager puede gestionar los límites del regulador por paquete; para clientes concretos pueden aplicarse valores diferentes. Por lo tanto, documenta cada vez que realices un cambio el Origen del límite: ¿Proviene del paquete o se ha configurado de forma individual? De este modo, más adelante se podrá saber qué clientes se ven afectados por un cambio de tarifa y qué excepciones deben revisarse por separado.

Comprobar la carga actual y el historial

Para el diagnóstico necesitas tanto una Instantánea así como la evolución a lo largo del tiempo. Los siguientes comandos se ejecutan en el terminal del servidor CloudLinux, no en la consola de MySQL. Su finalidad es ofrecer información y no modifican ningún límite; para realizar un análisis significativo, es necesario tener instaladas las herramientas correspondientes y disponer de los datos pertinentes.

Cuentas similares que llaman la atención con la Asignación de usuarios y del modo de funcionamiento seleccionado. Si falta un usuario de la base de datos en la asignación, la carga visible para la cuenta de alojamiento puede estar incompleta. La documentación de integración indica que los cambios en el archivo de asignación se aplican en un plazo de cinco minutos; por lo tanto, es posible que los resultados comprobados inmediatamente después aún no reflejen el nuevo estado.

A continuación, compara el momento en que se produjo la restricción con el proceso de uso observado. Un valor individual elevado puede corresponder a una importación y, por sí solo, no constituye prueba de un uso excesivo continuado. La Guía para interpretar los informes del gobernador de MySQL complementa la clasificación de los indicadores mostrados.

Distinguir entre la ralentización y sus causas

Si una página web se ralentiza, comprueba primero si en ese momento concreto había alguna restricción activa y qué motivo se indica. Relaciona este hallazgo con el proceso concreto: un proceso de pago lento y una importación que se está realizando al mismo tiempo pueden estar relacionados, pero no tiene por qué ser así. Sin una coincidencia temporal, sería precipitado determinar que el regulador es la única causa.

En el modo «Abusers» se ejecutan consultas limitadas a la base de datos en el LVE de la cuenta asignada. Allí comparten el Presupuesto de recursos con otros procesos de la cuenta, como PHP. Por eso, ante una queja, hay que tener en cuenta ambos aspectos: una tarea que requiera un uso intensivo de la base de datos puede competir por los recursos con PHP; a la inversa, la capacidad de LVE ya ocupada puede afectar a las consultas limitadas.

Si la carga se repite en una función de la tienda, analiza la consulta en cuestión y su Plan de consultas junto con las estadísticas adecuadas de la base de datos. La falta de un índice o un índice inadecuado es una posible causa, pero no la única. La limitación puede reducir el impacto en los recursos compartidos; sin embargo, no corrige ni el plan ni la lógica de la aplicación.

En el caso de «Single» y «Abusers», CloudLinux indica que las restricciones se levantan una vez que el uso ha estado por debajo de los umbrales durante un minuto. No obstante, comprueba el procedimiento de restricción realmente configurado y la evolución temporal en tu propio sistema, en lugar de deducir que se trata de una solución permanente a partir de un breve alivio. Una tarea que se reinicia puede volver a superar un umbral más adelante.

Reajustar los límites o modificar la arquitectura

Comienza el análisis preguntándote si el pico observado forma parte de una tarea prevista o si afecta de forma habitual al funcionamiento. Es posible que una importación programada se pueda posponer hasta una ventana de mantenimiento. Anota la duración, el recurso afectado y las repercusiones en la aplicación antes de deducir un cambio permanente en la tarifa a partir de un único pico.

Si ese margen de tiempo no es suficiente, se puede llevar a cabo una Excepción tarifaria puede ser más adecuado que un aumento general para todos los clientes. Documenta el motivo, la persona de contacto responsable y la fecha de la nueva revisión. Anota también si el valor actual procede del paquete o se ha establecido de forma individual: CloudLinux Manager admite límites relacionados con los paquetes y excepciones individuales.

Tras realizar un cambio, comprueba durante un periodo de tiempo representativo si el trabajo previsto se ejecuta mejor y si surgen restricciones o problemas en otros puntos. Para ello, compara los umbrales del regulador con los límites de LVE. Un umbral más alto permite, en principio, admitir más carga durante más tiempo; sin embargo, no garantiza ni el rendimiento ni unos tiempos de respuesta concretos.

Otro factor a tener en cuenta es la Solución del problema: La optimización de consultas, el uso de índices adecuados o el almacenamiento en caché pueden reducir el trabajo recurrente, en lugar de limitar únicamente sus efectos. Por el contrario, los límites de conexiones de la base de datos restringen los accesos simultáneos y no sustituyen automáticamente el control de la CPU y las E/S que realiza el «governor».

Si las necesidades de un cliente se alejan de forma significativa y duradera del alojamiento compartido, puede resultar conveniente disponer de una instancia de base de datos propia o de un servidor propio. Sin embargo, esto traslada la decisión de los umbrales individuales a la planificación de la capacidad, el mantenimiento y el funcionamiento. Además, esta separación no debe presentarse de forma generalizada como garantía de un aislamiento total o de tiempos de respuesta fijos.