MySQL Governor: limitare le risorse del database dei singoli clienti di hosting

Cosa limita MySQL Governor

MySQL Governor È un componente di CloudLinux per i server di hosting condiviso, non una funzionalità generica di MySQL. Rileva il carico del database in base agli utenti associati e, in caso di superamento delle soglie prestabilite, può limitare le query tramite i Lightweight Virtual Environments (LVE). In questo modo è possibile valutare il carico dei singoli account di hosting in modo più dettagliato rispetto al semplice carico complessivo del server del database.

Al centro dell'attenzione ci sono CPU e I/O del disco rigido: Il Governor tiene conto del carico di calcolo e dell'attività di lettura e scrittura. Un utilizzo elevato può derivare, ad esempio, da un'importazione o da una query del negozio eseguita frequentemente. L'assegnazione a un account rende visibile tale utilizzo; spetta poi valutare nel contesto se esso sia adeguato alla rispettiva operazione.

Un limite del database per queste risorse non corrisponde a una quota di spazio di archiviazione. Un database di grandi dimensioni, ma utilizzato raramente, può generare un carico ridotto sulla CPU e sull’I/O; al contrario, un database di piccole dimensioni può essere sottoposto a un carico elevato a causa di numerosi accessi complessi. Anche i limiti di connessione rispondono a un’altra esigenza: limitano gli accessi, ma non sostituiscono automaticamente il controllo della CPU e dell’I/O.

Se una query viene limitata, ciò non significa necessariamente che sia errata. La limitazione può proteggere altri account da un carico elevato, ma allo stesso tempo rallentare un’applicazione legittima. Ciò non garantisce tempi di risposta certi, poiché il servizio di database, l’hardware e altri componenti dell’applicazione rimangono parti condivise del sistema.

Per comprendere l'interazione tra conti, carico e LVE, la panoramica integrativa relativa a Limitazione del carico sul database con CloudLinux MySQL Governor un altro punto di accesso. L’ambiente effettivamente installato e le impostazioni ivi applicabili rimangono determinanti per la configurazione concreta.

Verifica della versione e della compatibilità

Prima di definire i limiti del database, verifica innanzitutto Edizione e licenza. Secondo il produttore, CloudLinux OS Admin non include MySQL Governor. Un sistema CloudLinux di per sé non costituisce quindi una prova che il componente sia disponibile, concesso in licenza e installato sul server per l'edizione scelta.

Successivamente, devi considerare la combinazione tra versione di CloudLinux, pacchetto Governor e server di database. MySQL e MariaDB rappresentano rami di sviluppo distinti: il fatto che una versione di MySQL sia supportata non implica che una versione di MariaDB della stessa età funzioni nelle stesse condizioni. Anche il pannello di controllo utilizzato e la sua integrazione devono essere verificati.

I requisiti minimi dimostrano perché un'approvazione generica non sia sufficiente: per MySQL 8.4, CloudLinux richiede almeno MySQL Governor 1.2-129. MariaDB 11.4 richiede almeno la versione 1.2-122 del Governor e non è supportata nella documentazione del produttore per CloudLinux OS 7. Queste indicazioni si riferiscono ai rami citati e non sostituiscono la verifica delle altre combinazioni.

Tra gli ambienti di installazione, il produttore indica, tra gli altri, cPanel, Plesk, DirectAdmin, ISPmanager e InterWorx, oltre ai server senza pannello di controllo. In caso di pannello diverso o integrato autonomamente, è opportuno chiarire separatamente il supporto specifico e, in particolare, l’assegnazione degli utenti. La versione del database indicata non costituisce una garanzia di compatibilità con ogni combinazione di pannello di controllo e sistema operativo.

Prima di apportare qualsiasi modifica, prendi nota delle versioni e dei pacchetti esistenti e confrontali con la documentazione relativa alla configurazione di destinazione prevista. In questo modo potrai capire se sia necessario sostituire prima alcuni componenti, anziché considerare compatibile un’installazione esistente basandoti esclusivamente sul nome del database.

Assegnare account di hosting agli utenti del database

Affinché il carico possa essere assegnato a un cliente di hosting, è necessario che vi sia una corrispondenza corretta tra gli utenti del database e gli account di hosting. In caso di integrazione con il pannello di controllo, a tale scopo viene solitamente utilizzato il file /etc/container/dbuser-map aggiornato. Il Governor applica le modifiche a tale assegnazione, come indicato nella documentazione di integrazione, entro cinque minuti.

Un esempio: un account di hosting gestisce un negozio online e un blog separato, ciascuno dei quali utilizza un proprio utente del database. Se entrambi gli utenti sono associati allo stesso account, il carico del database può essere registrato in base a tale account. Se una delle voci manca o rimanda all’account sbagliato, l’assegnazione visualizzata non è affidabile ai fini di una valutazione relativa al cliente.

Controlla il Assegnazione degli utenti Pertanto, non solo durante la prima installazione. Anche dopo la creazione o lo spostamento di database e utenti, il pannello deve aggiornare correttamente l'assegnazione. In caso di controllo effettuato subito dopo una modifica, occorre tenere conto del tempo di aggiornamento documentato prima di dedurre che si tratti di un errore permanente sulla base di dati ancora non aggiornati.

Particolarmente importante è l’assenza di mappatura nella modalità “Abusers”: secondo il produttore, in questa modalità il sistema emula la modalità “Single”. Gli utenti con restrizioni condividono nella modalità “Single” un unico LVE con restrizioni, invece di essere limitati ciascuno nel proprio LVE utente. L’attivazione della modalità «Abusers» da sola non dimostra quindi che la limitazione prevista a livello di singolo account sia effettivamente in vigore.

In caso di anomalie, verificare che gli utenti del database interessati, l’assegnazione configurata e la modalità operativa selezionata corrispondano tra loro. Anche una mappatura corretta non garantisce un isolamento completo: il servizio di database e l’hardware sottostante continuano a essere condivisi. L’assegnazione è un prerequisito per il controllo personalizzato in base al cliente, non un sostituto della pianificazione delle capacità.

Confronto tra le modalità operative

La modalità operativa determina se MySQL Governor si limiti a monitorare il carico del database oppure esegua query in un ambiente limitato. Per la scelta non sono importanti solo le soglie: anche l’assegnazione degli utenti del database e la questione di quali clienti condividano un LVE influenzano l’effetto.

Per fare il punto della situazione, si può ricorrere a Spento A: L'utilizzo osservato indica quali account e quali periodi meritano un'analisi più approfondita, senza che il Governor limiti le query. Tuttavia, un singolo valore istantaneo elevato non è di per sé indicativo del fatto che un account generi un carico elevato in modo persistente o che stia semplicemente eseguendo un'operazione di manutenzione legittima.

All'indirizzo Abusatori Le query al database soggette a limitazioni condividono il budget di risorse LVE con altri processi dello stesso account, come ad esempio PHP. Una limitazione può quindi non solo allungare la durata delle query: anche l’applicazione può rispondere più lentamente se i suoi processi competono per le stesse risorse limitate. Viceversa, il budget PHP già occupato può influire sul funzionamento del database.

L'impostazione "Single" è obsoleta ed è rilevante soprattutto per le configurazioni esistenti e per il comportamento di sostituzione documentato: più clienti con restrizioni condividono un ambiente e possono competere tra loro al suo interno. Se manca il file dbuser-map, Abusers emula questo comportamento; dall'impostazione selezionata da sola non è quindi possibile dedurre l'esistenza di una restrizione specifica del cliente. Anche l’impostazione «All» è obsoleta e non costituisce una raccomandazione standard per una nuova installazione.

Pianificazione dei limiti del database e delle fasce orarie

MySQL Governor distingue tra utilizzo della CPU e I/O di lettura e scrittura. L'interfaccia CLI documentata mostra la CPU in percentuale e l'I/O in MB/s; per la lettura e la scrittura è possibile configurare valori distinti. Questi parametri descrivono carichi di lavoro diversi: un’operazione che richiede un’elevata potenza di calcolo non comporta necessariamente una scrittura particolarmente intensa sul supporto dati.

Le traversine corrente, breve, medio e lungo Prendono in considerazione un utilizzo sia a breve termine che prolungato. Il loro superamento comporta una limitazione a seconda della modalità operativa e della configurazione. Non si tratta né di una velocità di trasmissione garantita né di quattro garanzie di prestazione indipendenti l’una dall’altra e applicate in modo rigido e permanente. La limitazione effettivamente applicata dipende anche dalla procedura selezionata e dai limiti LVE.

Un’importazione mette in evidenza la differenza: se il carico di scrittura aumenta brevemente per poi ridursi nuovamente, ciò può rientrare in un’operazione pianificata. Se invece rimane elevato per un periodo prolungato, l’importazione impegna le risorse più a lungo. Per prendere una decisione, oltre al valore di picco, dovresti verificare quale risorsa è interessata, quanto dura l’operazione e se si ripete.

Basso Soglie di attivazione possono proteggere gli altri clienti da un carico prolungato, ma potrebbero ostacolare importazioni legittime o interventi di manutenzione. Soglie elevate lasciano maggiore margine di manovra per tali attività, ma allo stesso tempo consentono un carico più elevato per un periodo più lungo. Una finestra di manutenzione o una capacità pianificata in modo mirato può essere più sensata di un’eccezione permanente.

Pianifica i valori del Governor in relazione ai limiti LVE e alle tariffe effettivamente offerte. Le raccomandazioni del produttore tengono espressamente conto di questa correlazione; da esse non è possibile ricavare valori di produzione universalmente validi. Il carico di richieste osservato, l’efficienza delle interrogazioni e la natura dei lavori dei clienti costituiscono la base per adeguare in modo controllato le soglie dopo l’introduzione.

Preparare l'introduzione e i limiti tariffari

Prima dell'installazione o dell'aggiornamento è necessario backup completo del database comprese le tabelle di sistema. Pianifica anche come dovrà avvenire il ripristino in caso di necessità. Il produttore sottolinea che i pacchetti del database possono essere aggiornati dai repository di CloudLinux; la sostituzione di un pacchetto non è quindi un effetto collaterale irrilevante che dovresti verificare solo dopo l'installazione.

Verifica quindi la combinazione tra edizione e versione di CloudLinux, licenza, ramo del database, pacchetto Governor e pannello di controllo. Il fatto che una versione del database sia supportata non garantisce di per sé che ogni combinazione di questi componenti sia supportata. Se le versioni dei pacchetti o l’integrazione con il pannello di controllo non corrispondono, è necessario chiarire il supporto specifico prima di procedere con qualsiasi intervento.

Dopo la preparazione tecnica, inizia con il monitoraggio anziché procedere immediatamente alla limitazione. Confronta gli orari di lavoro tipici con le finestre di importazione e manutenzione note e verifica che gli utenti del database siano assegnati agli account di hosting corretti. Senza un'assegnazione affidabile, non è possibile dedurre con certezza il fabbisogno effettivo di risorse da un carico apparente dell'account apparentemente basso.

Partendo da questa analisi della situazione, definisci una fase introduttiva limitata: stabilisci quali conti o tariffe devono essere interessati, come registrare i reclami e in base a quali osservazioni verificare l’impostazione. Dopo l’attivazione, confronta le limitazioni con le operazioni effettive, invece di considerare ogni superamento come un comportamento scorretto.

CloudLinux Manager consente di gestire i limiti del governor a livello di pacchetto; per i singoli clienti possono essere applicati valori diversi. Pertanto, ad ogni modifica, documentare il Origine del limite: Deriva dal pacchetto o è impostato individualmente? In questo modo sarà possibile risalire in seguito a quali clienti sono interessati da una modifica tariffaria e quali eccezioni devono essere verificate separatamente.

Verifica del carico attuale e dell'andamento

Per la diagnosi ti serve sia una Istantanea nonché l'andamento nel tempo. I comandi seguenti vengono eseguiti nel terminale del server CloudLinux, non nella console di MySQL. Servono a fini di consultazione e non modificano alcun limite; per un'analisi significativa è necessario che siano installati gli strumenti appropriati e che i dati rilevanti siano disponibili.

Stessi conti sospetti con il Assegnazione degli utenti e dalla modalità operativa selezionata. Se nel mapping manca un utente del database, il carico visibile per l'account di hosting potrebbe risultare incompleto. La documentazione sull'integrazione indica che le modifiche al file di mappatura vengono applicate entro cinque minuti; pertanto, un output verificato immediatamente dopo potrebbe non riflettere ancora lo stato aggiornato.

Confronta quindi il momento in cui si è verificata una limitazione con il processo di utilizzo osservato. Un valore singolo elevato può essere correlato a un’importazione e, di per sé, non costituisce prova di un utilizzo eccessivo prolungato. Il Guida alla lettura dei report del Governor di MySQL integra l'interpretazione degli indicatori visualizzati.

Distinguere tra limitazione e cause

Se un sito web diventa lento, verifica innanzitutto se in quel momento era attiva una limitazione e quale motivo viene indicato. Metti in relazione questo risultato con l’operazione specifica: un checkout lento e un’importazione in corso contemporaneamente possono essere correlati, ma non necessariamente. In assenza di una coincidenza temporale, sarebbe affrettato individuare nel Governor l’unica causa.

Nella modalità "Abusers" vengono eseguite query limitate sul database nell'LVE dell'account associato. Lì condividono il Bilancio delle risorse con altri processi in esecuzione, come ad esempio PHP. Pertanto, in caso di reclamo, è opportuno considerare entrambi i punti di vista: un’operazione che richiede un uso intensivo del database può entrare in competizione con PHP per le risorse; viceversa, la capacità di LVE già occupata può influire sulle query soggette a limitazioni.

Se il carico si ripete in una funzione dello shop, esamina la query in questione e il suo Piano di interrogazione insieme alle statistiche appropriate del database. Un indice mancante o inadeguato è una possibile causa, ma non l’unica. La limitazione può ridurre l’impatto sulle risorse condivise; tuttavia, non corregge né il piano né la logica dell’applicazione.

Per i profili "Single" e "Abusers", CloudLinux specifica che le restrizioni vengono revocate dopo che l'utilizzo è rimasto al di sotto delle soglie per un minuto. Verifica comunque la procedura di restrizione effettivamente configurata e l'andamento temporale sul proprio sistema, invece di dedurre immediatamente una soluzione permanente da un breve periodo di alleggerimento del carico. Un'attività che viene riavviata potrebbe superare nuovamente la soglia in un secondo momento.

Ricalibrare i limiti o modificare l'architettura

Inizia la valutazione chiedendoti se il picco osservato sia correlato a un’attività prevista o se comprometta regolarmente il funzionamento del sistema. Un'importazione pianificata potrebbe essere spostata in una finestra di manutenzione. In tal caso, registra la durata, la risorsa interessata e l'impatto sull'applicazione prima di dedurre una modifica tariffaria permanente da un singolo picco.

Se l'intervallo di tempo non è sufficiente, è possibile effettuare un'azione mirata Deroga tariffaria potrebbe essere più appropriato rispetto a un aumento forfettario per tutti i clienti. Documenta il motivo, il referente responsabile e la data della nuova verifica. Indica anche se il valore attuale deriva dal pacchetto o è stato impostato individualmente: CloudLinux Manager supporta limiti legati ai pacchetti e deroghe individuali.

Dopo aver apportato una modifica, verifica, per un periodo di tempo rappresentativo, se il carico di lavoro previsto viene elaborato in modo più efficiente e se si verificano limitazioni o problemi in altri punti. A tal fine, metti in relazione le soglie del governor con i limiti LVE. Una soglia più alta consente potenzialmente di gestire un carico maggiore per un periodo più lungo; non costituisce né una garanzia di throughput né un impegno a rispettare determinati tempi di risposta.

Un altro fattore determinante è il Risoluzione del problema: L'ottimizzazione delle query, l'utilizzo di indici adeguati o il caching possono ridurre il carico di lavoro ricorrente, anziché limitarsene semplicemente a mitigarne gli effetti. I limiti di connessione a livello di database, invece, limitano gli accessi simultanei e non sostituiscono automaticamente il controllo della CPU e dell'I/O da parte del Governor.

Se le esigenze di un cliente si discostano in modo significativo e duraturo dall’hosting condiviso, può essere opportuno ricorrere a un’istanza di database dedicata o a un server dedicato. Ciò sposta tuttavia la decisione dalla valutazione di singole soglie alla pianificazione della capacità, della manutenzione e della gestione. Anche una tale separazione non dovrebbe essere presentata in modo generalizzato come garanzia di isolamento totale o di tempi di risposta fissi.