Saltar para o conteúdo 
O CloudLinux MySQL Governor limita a carga da base de dados por conta e distribui-a de forma equitativa, para que as consultas individuais não abrandem todo o serviço de alojamento. Eu utilizo o MySQL Governor, para monitorizar em tempo real o consumo de CPU, as operações READ e WRITE por utilizador e, em caso de excedentes, limitar automaticamente o consumo.
Pontos centrais
- Conta Pro em vez de limites globais
- CPU/LEITURA/ESCRITA gerir separadamente
- Modos «Monitor-only» e abusos li>LVE como segundo nível de proteção
- Ferramentas CLI para controlo
Por que é que algumas consultas específicas atrasam tudo
Em ambientes de alojamento partilhado, geralmente são poucos os que geram Consultas a maior parte da carga, e não o volume das bases de dados. Vejo frequentemente que uma consulta com erros ou um plugin com elevado I/O passa subitamente a monopolizar o tempo de CPU e a latência aumenta de forma percetível para os outros utilizadores. É precisamente aqui que entra em ação o Governador porque torna visível a carga por utilizador e não se limita a considerar apenas a média global. Desta forma, evito que um „vizinho barulhento“ paralisem todos os outros projetos, apesar de as suas cargas de trabalho estarem dentro dos limites normais. Com limites claros e uma distribuição justa, consigo manter os tempos de resposta previsíveis e eliminar a base para acessos excessivos.
É assim que o MySQL Governor funciona no dia a dia
Costumo começar no MonitorModo «-only» para medir a utilização real sem intervir. Em seguida, ativo o modo «Abusen», que transfere automaticamente as contas com utilização excessiva para um ambiente restrito, mitigando assim imediatamente o impacto. A medição baseia-se em Tópico-Estatísticas por ligação MySQL/MariaDB, o que permite acompanhar a utilização da CPU e as percentagens de leitura e escrita por utilizador. Em caso de sobrecarga prolongada, é também ativado o LVE atribuído, o que leva a uma maior limitação dos processos destas contas. Este processo em duas fases evita escaladas, atenua picos de tráfego e protege de forma fiável os projetos não envolvidos.
Escolher valores-limite e intervalos de tempo de forma adequada
Estabeleço limites em vários Intervalos, para que eu possa tolerar picos de curta duração, mas interromper de forma fiável uma sobrecarga prolongada. Os intervalos de tempo curtos podem ter valores mais elevados, os médios devem ser moderados e os longos, claramente mais restritivos, devendo todos permanecer abaixo dos limites globais de LVE. Mede a utilização da CPU como percentagem por Núcleo; com oito núcleos, 100% corresponde a um núcleo completo, o que garante que a distribuição e a equidade se mantêm transparentes. Avalio os READ e WRITE com base em E/S reais do disco, ou seja, sem acertos na cache, para poder ver a carga real no armazenamento. Para uma configuração global adequada, sigo as regras comprovadas do LVE e detalhes como os descritos em Configurar corretamente os limites do LVE descrito.
Planear intervalos de acordo com a hora do dia e os perfis
Tenho todo o prazer em deixar aqui perfis em função da hora do dia: Durante o horário de pico, permito intervalos curtos de forma um pouco mais flexível, para dar resposta a picos de tráfego legítimos (por exemplo, promoções relâmpago na loja). À noite e durante a madrugada, prefiro sobretudo a intervalos longos Mais rigoroso, para que as tarefas de longa duração não esgotem o disco sem que se dê por isso. Para as janelas de processamento em lote, defino perfis próprios com um pouco mais de WRITE, mas com CPU limitada, para que as importações decorram rapidamente, mas sem monopolizar os recursos. O importante é: nunca altero todos os parâmetros ao mesmo tempo. Primeiro, ajusto a CPU, observo e, só depois, o READ/WRITE. Cada alteração tem um período de observação definido, para que a causa e o efeito possam ser claramente distinguidos.
Ferramentas CLI e diagnóstico rápido
Analiso contas suspeitas com dbtop em tempo real, atualizo os limites com o dbctl e consulto os registos históricos através do lveinfo –dbgov. Estas ferramentas fornecem-me, em poucos segundos, os dados relevantes sobre picos de tráfego, consultas de longa duração e números de ligações por utilizador. Assim, consigo perceber se, sobretudo, CPU ou se há limitações de E/S, se as ligações estão a ficar excessivas ou se determinadas tabelas estão a acumular consultas. A partir desses padrões, determino valores-limite ajustados para cada intervalo e testo as alterações, numa primeira fase, apenas em modo de monitorização. Só quando as curvas apresentam uma descida plausível é que ativo a limitação de forma permanente.
| Ferramenta | Objetivo | Exemplo |
|---|---|---|
| dbtop | Visualização em tempo real por utilizador/tópico | dbtop – por utilizador |
| dbctl | Estabelecer limites e controlar os modos | dbctl set userX cpu=120 read=8 write=6 |
| lveinfo –dbgov | Verificar o histórico e as infrações | lveinfo –dbgov –id userX –period 1h |
Resolução de problemas: padrões típicos e medidas rápidas para os resolver
Quando CPU de uma conta, encontro frequentemente padrões como SELECT *, cláusulas WHERE em falta, ORDER BY complexas com conjuntos de resultados grandes ou consultas N+1 provenientes de ORMs. No que diz respeito à E/S, vejo varreduras completas sem índices adequados, repetições de LIKE ‚%…%‘ ou JOINs em colunas não indexadas. O meu procedimento: identificar as tabelas afetadas, verificar o plano de consulta, adicionar os índices em falta e a consulta simplificar (apenas as colunas necessárias, paginação com LIMIT/OFFSET ou abordagens com cursor). Paralelamente, defino temporariamente restrições mais rigorosas para este utilizador intervalos curtos, para que o pico seja imediatamente atenuado, e volte a afrouxá-las assim que a correção estiver em produção e a curva apresentar uma descida estável.
Interação com o LVE: controlo em duas fases
Considero o MySQL Governor como primeiro Camada de proteção da base de dados e o LVE como segundo mecanismo de travagem, caso a carga se mantenha por mais tempo. O Governor limita de forma seletiva a atividade da base de dados, enquanto o LVE controla rigorosamente a CPU, a RAM e as E/S da conta no seu conjunto. Esta combinação impede que uma conta escape ao controlo através da mera repetição de consultas curtas. Se a atividade se mantiver elevada, entra em ação LVE e reduz a prioridade do processo da conta, o que alivia sensivelmente a carga da base de dados. Desta forma, a qualidade do serviço mantém-se fiável para todos os clientes, mesmo durante picos de carga e de tráfego.
Valores-limite na prática: valores de exemplo
Nos servidores partilhados típicos, começo com CPU-Limites entre 80–150% por conta no intervalo curto e reduzo significativamente no intervalo longo. Quanto à LEITURA/ESCRITA, costumo começar com 4–12 MB/s a curto prazo e ir reduzindo gradualmente a longo prazo, para que o disco não entre num estado de espera contínua. Gosto de limitar o número de ligações simultâneas a 30, porque ligações excessivas esgotam rapidamente os conjuntos de threads. Esses valores iniciais servem de base, mas eu ajusto-os com base em dados reais do dbtop e do lveinfo. O importante é isto: posso permitir picos de curta duração, mas evito sistematicamente que os recursos sejam esgotados de forma prolongada.
Exceções, listas de autorização e janelas de manutenção
Algumas contas precisam, por vezes, de mais espaço: grandes Importações, migrações de lojas, reindexação. Planeio essas ações em intervalos de tempo fora dos horários de maior utilização e defino antecipadamente limites temporariamente mais elevados por utilizador. Após a conclusão, restabeleço os valores padrão através de um script. Também é aconselhável uma pequena Lista branca para contas essenciais ao sistema, que nunca devem ser limitadas (por exemplo, utilizadores de serviços internos). Documento cada exceção com a hora de início e de fim e os valores-alvo, para que análises posteriores possam explicar o desvio. Desta forma, a governação mantém-se transparente, sem impedir trabalhos de manutenção legítimos.
WordPress e plugins: resolver os problemas mais comuns
Nas configurações de CMS, vejo frequentemente JOINs, widgets dinâmicos sem cache e tarefas cron que analisam tabelas completas de hora a hora. O Governor protege de forma fiável neste caso, mas resolvo também a causa ao nível da aplicação. Ativo o cache de objetos, reduzo as consultas de pesquisa e utilizo, sempre que for adequado, Agrupamento de ligações, para evitar picos de ligações e desligações. Em combinação com limites claros de CPU/IO, consigo reduzir sensivelmente os tempos de resposta e manter a Carga controlável. Esta combinação reduz o número de pedidos de assistência e atenua os picos antes que estes sobrecarreguem o servidor.
Manutenção de esquemas e índices na prática
Verifico regularmente se as tabelas e os índices ainda são relevantes para o Padrão de acesso adaptar. As novas funcionalidades e plugins alteram frequentemente as consultas de forma subtil: um filtro adicional, um critério de ordenação diferente – e, de repente, o índice antigo já não funciona. Por isso, dou prioridade aos índices para colunas WHERE frequentes, reduzo índices sobrepostos e substituo as pesquisas com o prefixo LIKE por campos mais específicos. Para tabelas de arquivo, utilizo conceitos de partição ou filtros de carimbo temporal para evitar varreduras completas. O Governor mitiga as consequências de esquemas inadequados, mas o mais eficiente é os dados de fácil acesso estruturar.
Gestão de ligações: evitar o erro 500
Um número excessivo de ligações simultâneas provoca frequentemente falhas nos serviços Intervalos, que se manifestam como erros 500. Primeiro, verifico a taxa de ligações por utilizador e a utilização do conjunto de threads. Caso haja indícios de picos de ligações, aplico limites mais restritivos e implemento o armazenamento em cache ao nível da consulta ou do objeto. Para complementar, o artigo sobre Erro 500 devido a ligações causas típicas e medidas para resolver este estrangulamento. Em suma, garanto a segurança da pilha do MySQL e mantenho a Latência previsível.
Dosear corretamente o pooling e o keep-alive
Faço o dimensionamento de piscinas pequeno, mas constante: o suficiente para cobrir o paralelismo típico, sem bloquear o servidor com sessões inativas. Tempos de keep-alive prolongados suavizam os picos de carga, mas não devem fazer com que muitas ligações inativas ocupem recursos. Por isso, medo o tempo de permanência e o tempo de inatividade por conta e regulo os tamanhos dos pools, bem como os tempos limite das sessões, em conformidade. Em conjunto com o Governor, evito assim que a criação e o encerramento descontrolados de ligações consumam recursos da CPU, ao mesmo tempo que evito que pools excessivamente grandes ocupem desnecessariamente o pool de threads.
Como interpretar corretamente os indicadores de monitorização
Faço uma distinção clara entre CPU e I/O, porque ambos os recursos impõem limitações totalmente diferentes. Se a utilização da CPU aumentar significativamente sem valores de I/O adequados, a lógica, a análise ou um plano ineficiente costumam bloquear o sistema; em caso de I/O elevado com baixa utilização da CPU, as varreduras completas ou a falta de índices indicam o gargalo. Avalio sempre as operações de LEITURA/ESCRITA sem cache, para identificar a carga real do disco e não apenas os acessos à memória. Além disso, analiso a duração da ligação, os threads ativos e o comprimento das consultas, para detetar precocemente as execuções lentas. A partir destes padrões, determino qual o limite a aplicar e qual o intervalo a definir de forma mais rigorosa.
Ter em conta os fatores relacionados com o hardware e o motor
O Classe de armazenamento determina quais os valores-limite que são viáveis. No NVMe, posso permitir valores de LEITURA/ESCRITA mais elevados a curto prazo; no HDD, planeio de forma mais conservadora e mantenho os intervalos longos de forma mais rigorosa. Além disso, observo como o motor armazena em buffer: os gravadores em segundo plano mais agressivos podem suavizar picos, mas também produzir fases aparentemente „calmas“, nas quais as gravações se atrasam. Por isso, correlaciono as métricas do regulador com a E/S física e os tempos de espera no dispositivo de bloco. O objetivo é sempre um mais estável Valores medianos em vez de valores máximos de débito, em detrimento da latência.
Comparação entre «Monitor-only» e «Abusen»
Eu uso o MonitorModo «-only» para recolher perfis de utilização reais e estabelecer valores de referência. Assim que definir limites plausíveis, mudo para o modo «Abusen», para que o «Governor» limite automaticamente as contas em caso de sobrecarga. O primeiro modo reduz os falsos alarmes, enquanto o segundo evita danos colaterais durante picos reais. Dependendo do meu nível de experiência, posso trabalhar com intervalos longos mais rigorosos e dar um pouco mais de margem nos intervalos curtos. Esta sequência garante que os limites não sejam definidos de forma arbitrária, mas sim com base numa Medição seguir.
Plano de implementação e comunicação
Nunca introduzo o Governor com o „Big Bang“. O procedimento é comprovado: 1) Inventário das contas ativas, agrupamento aproximado por perfis de carga. 2) Apenas monitor durante, pelo menos, uma a duas semanas, para registar os padrões semanais. 3) Definição de limites de referência por cluster e implementação controlada em fases, acompanhando de perto os KPIs (taxa de erros, latência P95, taxas de interrupção). 4) Ajuste fino e documentação das exceções. Paralelamente, informo os clientes de forma proativa sobre o objetivo „Fair Share“, as causas típicas das restrições e as otimizações recomendadas. A transparência reduz o número de questões e aumenta a aceitação dos limites.
Proteger a replicação, as cópias de segurança e os utilizadores especiais
Utilizadores com acesso privilegiado ao sistema, tais como Replicação- ou Utilizador de cópia de segurança não podem ser limitadas de forma inesperada. Classifico claramente essas contas, documento-as e excluo-as das limitações automáticas. Para as cópias de segurança, planeio limites de leitura que se situem abaixo da zona de conforto do armazenamento, para que a carga dos utilizadores não seja afetada em paralelo. No que diz respeito à replicação, certifico-me de que os processos de recuperação não comprometam a carga de produção: intervalos curtos são tratados de forma um pouco mais generosa, enquanto os intervalos longos são abordados de forma mais conservadora, para que a recuperação contínua não se torne um travão permanente. É importante manter uma separação clara entre Serviço- e contas de clientes, para que as métricas se mantenham unívocas.
Procedimentos de emergência em caso de sobrecarga aguda
Se, apesar dos limites, ocorrer uma degradação percetível, vou introduzir uma Manual de estratégias A partir de: 1) Identificar a conta com maior consumo no dbtop e restringir temporariamente os seus limites. 2) Reduzir o limite máximo de ligações para esse utilizador, a fim de aliviar a carga no conjunto de threads. 3) Identificar as consultas de longa duração e otimizar ou suspender prioritariamente as consultas que se destaquem. 4) Em caso de carga elevada no sistema, reduzir temporariamente os limites de LVE do utilizador problemático, para estabilizar a plataforma. 5) Após a situação se acalmar, reverter gradualmente as alterações e resolver a causa de forma definitiva (índice, cache, código). Registo cada medida com a hora e o efeito medido, para que futuras intervenções sejam mais rápidas.
Em resumo: orientações práticas
Apostam numa separação clara Limites para CPU, READ e WRITE, porque cada recurso tem um efeito diferente. Começo de forma conservadora, avalio os efeitos no modo «apenas monitorização» e defino limites no modo «abuso», assim que as curvas indicarem de forma fiável o rumo a seguir. Mantenho os intervalos de longo prazo mais rigorosos e fico abaixo dos limites globais de LVE, para que o segundo nível de proteção entre em ação com segurança, se necessário. Fico atento ao número de ligações, começo com 30 sessões por conta e ajusto consoante a carga de trabalho e a hora do dia. Combino o controlo técnico com o trabalho nas causas na aplicação, pois assim mantenho a Base de dados fiável, justo e ágil para todos os projetos no mesmo servidor.
