MySQL Governor: Limitar os recursos da base de dados de cada cliente de alojamento

O que o MySQL Governor limita

MySQL Governor É um componente do CloudLinux para servidores de alojamento partilhado, não sendo uma funcionalidade geral do MySQL. Regista a carga da base de dados com base nos utilizadores atribuídos e pode limitar as consultas, caso os limiares sejam ultrapassados, através dos Lightweight Virtual Environments (LVE). Desta forma, é possível analisar a carga de contas de alojamento individuais de forma mais diferenciada do que apenas a carga total do servidor da base de dados.

Em destaque estão CPU e E/S do disco rígido: O Governor analisa a carga computacional, bem como a atividade de leitura e gravação. Uma utilização elevada pode resultar, por exemplo, de uma importação ou de uma consulta à loja efetuada com frequência. A atribuição a uma conta torna essa utilização visível; se é adequada para a operação em questão, isso deve ser avaliado posteriormente no contexto.

Um limite de base de dados para estes recursos não corresponde a uma quota de espaço de armazenamento. Uma base de dados grande, mas raramente utilizada, pode causar pouca carga de CPU e de E/S em funcionamento; por outro lado, uma base de dados pequena pode ser fortemente sobrecarregada devido a muitos acessos dispendiosos. Os limites de ligações também respondem a uma questão diferente: limitam os acessos, mas não substituem automaticamente o controlo da CPU e das E/S.

Se uma consulta for limitada, isso não significa necessariamente que esteja errada. A limitação pode proteger outras contas de uma carga elevada, mas, ao mesmo tempo, pode tornar mais lenta uma aplicação legítima. Isso não garante tempos de resposta, uma vez que o serviço de base de dados, o hardware e outros componentes da aplicação continuam a ser partes partilhadas do sistema.

Para compreender a interação entre contas, débito e LVE, a visão geral complementar sobre a Limitação da carga da base de dados com o CloudLinux MySQL Governor uma outra forma de acesso. O ambiente efetivamente instalado e as configurações nele aplicáveis continuam a ser determinantes para a configuração concreta.

Verificar a edição e a compatibilidade

Antes de planear os limites da base de dados, verifica primeiro Edição e licença. Segundo o fabricante, o CloudLinux OS Admin não inclui o MySQL Governor. Por isso, o simples facto de se dispor de um sistema CloudLinux não constitui prova de que esse componente esteja disponível, licenciado e instalado no servidor para a edição escolhida.

Em seguida, deve ter em conta a combinação entre a versão do CloudLinux, o pacote Governor e o servidor de base de dados. O MySQL e o MariaDB são ramos de desenvolvimento distintos: o facto de uma versão do MySQL ser suportada não significa que uma versão do MariaDB com a mesma data de lançamento funcione nas mesmas condições. O painel de controlo utilizado e a sua integração também devem ser tidos em conta na análise.

Os requisitos mínimos mostram por que razão uma autorização genérica não é suficiente: para o MySQL 8.4, o CloudLinux exige, no mínimo, o MySQL Governor 1.2-129. O MariaDB 11.4 requer, no mínimo, a versão 1.2-122 do Governor e não é suportado para o CloudLinux OS 7 na documentação do fabricante. Estas informações referem-se aos ramos mencionados e não substituem a verificação das restantes combinações.

Como ambientes de instalação, o fabricante menciona, entre outros, o cPanel, o Plesk, o DirectAdmin, o ISPmanager e o InterWorx, bem como servidores sem painel de controlo. No caso de um painel diferente ou integrado pelo próprio utilizador, deve esclarecer separadamente o suporte específico e, em particular, a atribuição de utilizadores. A indicação de uma versão de base de dados na lista não constitui uma garantia de compatibilidade com todas as combinações de painéis e sistemas operativos.

Regista as versões e os pacotes existentes antes de efetuar qualquer alteração e compara-os com a documentação relativa à configuração pretendida. Desta forma, poderás verificar se, numa primeira fase, seria necessário substituir algum componente, em vez de considerar uma instalação existente como compatível apenas com base no nome da base de dados.

Atribuir contas de alojamento a utilizadores da base de dados

Para que a carga possa ser atribuída a um cliente de alojamento, é necessário que a correspondência entre os utilizadores da base de dados e as contas de alojamento esteja correta. Numa integração com o painel de controlo, utiliza-se normalmente o ficheiro /etc/container/dbuser-map atualizada. O Governor aplica as alterações a esta atribuição, de acordo com a documentação de integração, no prazo de cinco minutos.

Um exemplo: uma conta de alojamento aloja uma loja e um blogue separado, cada um dos quais funciona com um utilizador de base de dados próprio. Se ambos os utilizadores estiverem associados à mesma conta, a carga da base de dados pode ser registada de acordo com essa conta. Se faltar uma das entradas ou se esta apontar para a conta errada, a atribuição apresentada não é fiável para uma avaliação relacionada com o cliente.

Verifica o Atribuição de utilizadores Por isso, não se trata apenas da instalação inicial. Mesmo após a criação ou a deslocação de bases de dados e utilizadores, o painel tem de atualizar corretamente a atribuição. Ao efetuar uma verificação imediatamente após uma alteração, é necessário ter em conta o prazo de atualização documentado, antes de concluir que existe um erro permanente com base numa versão ainda desatualizada.

É particularmente importante a ausência de mapeamento no modo «Abusers»: segundo o fabricante, este modo emula então o modo «Single». Os clientes com restrições partilham, no modo «Single», um LVE comum e restrito, em vez de serem limitados, cada um, no seu próprio LVE de cliente. Por conseguinte, o simples facto de o modo «Abusers» estar ativado não prova, por si só, que a restrição pretendida para cada conta esteja efetivamente em vigor.

Em caso de anomalias, compare entre si os utilizadores da base de dados afetados, a atribuição definida e o modo de funcionamento selecionado. Mesmo um mapeamento correto não garante um isolamento total: o serviço de base de dados e o hardware subjacente continuam a ser partilhados. A atribuição é um pré-requisito para o controlo específico por cliente, não sendo um substituto para o planeamento de capacidade.

Comparação dos modos de funcionamento

O modo de funcionamento determina se o MySQL Governor se limita a monitorizar a carga da base de dados ou se executa consultas num ambiente restrito. Para esta escolha, não são apenas os limiares que importam: também a atribuição dos utilizadores da base de dados e a questão de saber quais os clientes que partilham uma LVE influenciam o resultado.

Para fazer um balanço, uma boa opção é Desligado Nota: A utilização observada indica quais as contas e os períodos que merecem uma análise mais aprofundada, sem que o Governor limite as consultas. No entanto, um único valor de pico elevado não indica, por si só, se uma conta gera uma carga elevada de forma permanente ou se está apenas a realizar um trabalho de manutenção legítimo.

Em Abusadores As consultas à base de dados com restrições partilham o orçamento de recursos do LVE com outros processos da mesma conta, como o PHP. Por isso, uma restrição pode não só prolongar as consultas, como também fazer com que a aplicação reaja mais lentamente, caso os seus processos disputem os mesmos recursos limitados. Por outro lado, o orçamento de PHP já ocupado pode influenciar o funcionamento da base de dados.

A opção «Single» está desatualizada e é relevante sobretudo para configurações existentes, bem como para o comportamento de substituição documentado: vários clientes com restrições partilham um ambiente e podem competir entre si nesse ambiente. Se faltar o ficheiro «dbuser-map», o Abusers emula este comportamento; a partir apenas da configuração selecionada, não é possível concluir que existe uma restrição específica do cliente. A opção «All» também está desatualizada e não é uma recomendação habitual para uma nova instalação.

Planear limites da base de dados e intervalos de tempo

O MySQL Governor distingue entre a utilização da CPU e as operações de E/S de leitura e escrita. A CLI documentada apresenta a utilização da CPU em percentagem e as operações de E/S em MB/s; é possível configurar valores separados para leitura e escrita. Estes valores descrevem cargas diferentes: um processo que exige um grande esforço computacional não tem necessariamente de escrever uma quantidade significativa de dados no suporte de dados.

Os travessões curto, médio e longo prazo Consideram a utilização a curto prazo e a longo prazo. A sua ultrapassagem desencadeia uma restrição, dependendo do modo de funcionamento e da configuração. Não se trata nem de uma taxa de transferência garantida, nem de quatro compromissos de desempenho independentes entre si e permanentemente impostos de forma rígida. A restrição que efetivamente se aplica depende também do procedimento selecionado e dos limites de LVE.

Uma importação ilustra bem a diferença: se a carga de escrita aumentar brevemente e depois voltar a diminuir, isso pode fazer parte de uma operação de trabalho planeada. Se se mantiver elevada durante um período mais longo, a importação consome recursos por mais tempo. Para tomar uma decisão, além do valor de pico, deves verificar qual é o recurso afetado, quanto tempo dura o processo e se este se repete.

Baixa Limiares de ativação podem proteger outros clientes mais cedo contra uma carga prolongada, mas podem também limitar importações legítimas ou trabalhos de manutenção. Limiares elevados dão mais margem de manobra a esses trabalhos, mas, ao mesmo tempo, permitem uma carga mais elevada durante mais tempo. Uma janela de manutenção ou uma capacidade planeada de forma específica pode fazer mais sentido do que uma exceção permanente.

Planeie os valores do regulador em função dos limites do LVE e das tarifas efetivamente oferecidas. As recomendações do fabricante têm expressamente em conta esta relação; no entanto, não é possível deduzir daí valores de produção universalmente válidos. A carga de pedidos observada, a eficiência das consultas e o tipo de trabalhos dos clientes constituem a base para ajustar os limiares de forma controlada após a implementação.

Preparar a implementação e os limites tarifários

Antes da instalação ou atualização, é necessário cópia de segurança completa da base de dados incluindo as tabelas do sistema. Planeia também como deverá ser feita a recuperação, caso seja necessário. O fabricante salienta que os pacotes de bases de dados podem ser atualizados a partir dos repositórios do CloudLinux; por isso, a mudança de pacote não é um efeito secundário sem consequências que só devas verificar após a instalação.

Em seguida, verifique a combinação entre a edição e a versão do CloudLinux, a licença, o ramo da base de dados, o pacote Governor e o Painel de Controlo. O facto de uma versão da base de dados ser suportada, por si só, não garante que todas as combinações destes componentes sejam suportadas. Se as versões dos pacotes ou a integração do painel não estiverem corretas, é necessário esclarecer se existe suporte específico antes de proceder a qualquer intervenção.

Após a preparação técnica, comece por observar em vez de reduzir imediatamente a capacidade. Compare os horários normais de funcionamento com as janelas de importação e manutenção conhecidas e verifique se os utilizadores da base de dados estão atribuídos às contas de alojamento corretas. Sem uma atribuição fiável, não é possível concluir com segurança quais são as necessidades reais de recursos com base numa carga aparentemente baixa nas contas.

A partir deste balanço, elabore uma implementação limitada: defina quais as contas ou tarifas que devem ser abrangidas, como as reclamações devem ser registadas e com base em que observações irá verificar a configuração. Após a ativação, compare as restrições com os processos de utilização, em vez de considerar cada excedência imediatamente como uma infração.

O CloudLinux Manager permite gerir os limites do Governor por pacote; podem aplicar-se valores diferentes para clientes individuais. Por isso, documente, sempre que houver uma alteração, o Origem do limite: Provém do pacote ou foi definido individualmente? Desta forma, será possível verificar posteriormente quais os clientes afetados por uma alteração na tarifa e quais as exceções que têm de ser analisadas separadamente.

Verificar a carga atual e o histórico

Para o diagnóstico, precisas tanto de uma Instantâneo bem como a evolução ao longo do tempo. Os comandos que se seguem são executados no terminal do servidor CloudLinux, e não na consola do MySQL. Servem apenas para fins informativos e não alteram quaisquer limites; para uma análise significativa, é necessário que as respetivas ferramentas estejam instaladas e que os dados relevantes estejam disponíveis.

Identifique contas suspeitas com a Atribuição de utilizadores e do modo de funcionamento selecionado. Se faltar um utilizador da base de dados no mapeamento, a carga visível para a conta de alojamento pode estar incompleta. A documentação de integração indica que as alterações ao ficheiro de mapeamento são aplicadas no prazo de cinco minutos; por isso, um resultado verificado imediatamente a seguir pode ainda não refletir o novo estado.

Em seguida, compare o momento em que ocorreu uma restrição com o processo de utilização observado. Um valor isolado elevado pode estar relacionado com uma importação e, por si só, não constitui prova de uma utilização excessiva prolongada. A Guia para a leitura dos relatórios do MySQL Governor complementa a interpretação dos indicadores apresentados.

Distinguir entre limitação e causas

Se um site ficar lento, verifica primeiro se, naquele momento, havia alguma restrição ativa e qual é o motivo indicado. Relaciona essa constatação com o processo específico: um processo de checkout lento e uma importação a decorrer em simultâneo podem estar relacionados, mas não têm de estar. Sem uma coincidência temporal, seria precipitado determinar que o «Governor» é a única causa.

No modo «Abusers», são executadas consultas restritas à base de dados no LVE da conta associada. Aí, partilham o Orçamento de recursos com outros processos de conta, como o PHP. Por isso, em caso de reclamação, considere ambos os lados: uma tarefa que exija um uso intensivo da base de dados pode competir com o PHP pelos recursos; por outro lado, a capacidade do LVE já ocupada pode afetar as consultas limitadas.

Se a carga se repetir numa função da loja, analisa a consulta em questão e o seu Plano de consulta juntamente com estatísticas adequadas da base de dados. A ausência de um índice ou a utilização de um índice inadequado é uma causa possível, mas não a única. A limitação pode reduzir o impacto nos recursos partilhados; não corrige nem o plano nem a lógica da aplicação.

No caso do modo «Single» e do «Abusers», o CloudLinux indica que as restrições são levantadas após o consumo ter ficado abaixo dos limiares durante um minuto. No entanto, verifica o procedimento de restrição efetivamente configurado e a evolução temporal no teu próprio sistema, em vez de concluíres imediatamente que se trata de uma solução permanente com base numa breve redução da carga. Uma tarefa que seja reiniciada pode voltar a ultrapassar um limite mais tarde.

Reajustar os limites ou alterar a arquitetura

Começa a análise perguntando se o pico observado faz parte de uma tarefa prevista ou se afeta regularmente o funcionamento. Uma importação planeada pode, eventualmente, ser adiada para uma janela de manutenção. Registe a duração, o recurso afetado e o impacto na aplicação antes de deduzir uma alteração permanente da tarifa a partir de um pico isolado.

Se o intervalo de tempo não for suficiente, pode ser realizada uma Exceção tarifária pode ser mais adequado do que um aumento generalizado para todos os clientes. Registe o motivo, o contacto responsável e a data da nova verificação. Indique também se o valor atual provém do pacote ou se foi definido individualmente: o CloudLinux Manager suporta limites relacionados com pacotes e variações individuais.

Após uma alteração, verifica, durante um período de tempo representativo, se o trabalho pretendido é processado de forma mais eficiente e se surgem restrições ou problemas noutros pontos. Ao fazê-lo, compara os limiares do regulador com os limites do LVE. Um limiar mais elevado permite, potencialmente, suportar mais carga durante mais tempo; não constitui, no entanto, uma garantia de débito nem uma promessa de tempos de resposta específicos.

Outro fator a ter em conta é o Resolução da causa: A otimização de consultas, a utilização de índices adequados ou o armazenamento em cache podem reduzir o trabalho recorrente, em vez de se limitarem apenas a mitigar os seus efeitos. Por outro lado, os limites de ligações do lado da base de dados restringem os acessos simultâneos e não substituem automaticamente o controlo da CPU e das E/S do Governor.

Se os requisitos de um cliente se desviarem significativamente e de forma duradoura do alojamento partilhado, pode fazer sentido dispor de uma instância de base de dados própria ou de um servidor próprio. No entanto, isso desloca a decisão de limites específicos para o planeamento da capacidade, manutenção e operação. Além disso, tal separação não deve ser apresentada de forma generalizada como garantia de isolamento total ou de tempos de resposta fixos.