MySQL Governor: de databasebronnen van individuele hostingklanten beperken

Wat de MySQL Governor beperkt

MySQL Governor is een CloudLinux-component voor shared-hostingservers, geen algemene functie van MySQL. Het meet de databasebelasting op basis van de toegewezen gebruikers en kan, wanneer drempelwaarden worden overschreden, het aantal query’s beperken via Lightweight Virtual Environments, kortweg LVE. Zo kan de belasting van afzonderlijke hostingaccounts gedifferentieerder worden bekeken dan alleen de totale belasting van de databaseserver.

De nadruk ligt op CPU en harde-schijf-I/O: De Governor houdt rekening met de rekenbelasting en de lees- en schrijfactiviteit. Een hoog verbruik kan bijvoorbeeld het gevolg zijn van een import of een veelvuldig uitgevoerde winkelquery. Door de toewijzing aan een account wordt dit verbruik zichtbaar; of het in verhouding staat tot de betreffende transactie, moet vervolgens in de context worden beoordeeld.

Een databaselimiet voor deze bronnen is geen opslagruimtequotum. Een grote, zelden gebruikte database kan weinig lopende CPU- en I/O-belasting veroorzaken; omgekeerd kan een kleine database door veel intensieve toegangen zwaar worden belast. Ook verbindingslimieten beantwoorden een andere vraag: ze beperken het aantal toegangen, maar vervangen niet automatisch de regeling van CPU en I/O.

Als een query wordt afgeremd, betekent dat niet per se dat deze foutief is. De beperking kan andere accounts beschermen tegen een hoge belasting, maar tegelijkertijd een legitieme toepassing vertragen. Dit leidt niet tot gegarandeerde responstijden, aangezien de databaseservice, de hardware en andere applicatiecomponenten gedeelde onderdelen van het systeem blijven.

Voor een beter begrip van de onderlinge samenhang tussen rekeningen, lasten en LVE biedt het aanvullende overzicht van de Beperking van de belasting van de database met CloudLinux MySQL Governor een andere manier om te beginnen. Bepalend voor de concrete configuratie blijven de daadwerkelijk geïnstalleerde omgeving en de instellingen die daar gelden.

Controleer de versie en compatibiliteit

Voordat je de limieten voor de database vaststelt, controleer je eerst Uitgave en licentie. Volgens de fabrikant bevat CloudLinux OS Admin geen MySQL Governor. Een CloudLinux-systeem op zich is daarom geen bewijs dat deze component voor de gekozen editie beschikbaar is, in licentie is gegeven en op de server is geïnstalleerd.

Vervolgens bekijk je de combinatie van de CloudLinux-versie, het Governor-pakket en de databaseserver. MySQL en MariaDB zijn daarbij afzonderlijke ontwikkelings takken: het feit dat een bepaalde MySQL-versie wordt ondersteund, betekent niet dat een MariaDB-versie van dezelfde leeftijd onder dezelfde omstandigheden werkt. Ook het gebruikte configuratiescherm en de integratie daarvan moeten worden gecontroleerd.

De minimumversies laten zien waarom een algemene goedkeuring niet volstaat: voor MySQL 8.4 vereist CloudLinux minimaal MySQL Governor 1.2-129. MariaDB 11.4 vereist minimaal versie 1.2-122 van de Governor en wordt in de documentatie van de fabrikant niet ondersteund voor CloudLinux OS 7. Deze gegevens hebben betrekking op de genoemde branches en vervangen niet de controle van de overige combinaties.

Als installatieomgevingen noemt de fabrikant onder andere cPanel, Plesk, DirectAdmin, ISPmanager en InterWorx, evenals servers zonder configuratiescherm. Bij een afwijkend of zelf geïntegreerd configuratiescherm moet je de concrete ondersteuning en met name de gebruikerstoewijzing apart afstemmen. Een vermelde databaseversie is geen garantie voor elke combinatie van controlepaneel en besturingssysteem.

Noteer de huidige versies en pakketten voordat je wijzigingen aanbrengt en vergelijk deze met de documentatie voor de beoogde doelconfiguratie. Zo kun je vaststellen of er eerst een component moet worden vervangen, in plaats van een bestaande installatie louter op basis van de databasenaam als compatibel te beschouwen.

Databasegebruikers toewijzen aan hostingaccounts

Om de belasting aan een hostingklant te kunnen toewijzen, moet de koppeling tussen databasegebruikers en hostingaccounts kloppen. Bij een panelintegratie wordt hiervoor doorgaans het bestand /etc/container/dbuser-map bijgewerkt. De Governor neemt wijzigingen in deze toewijzing binnen vijf minuten over, conform de integratiedocumentatie.

Een voorbeeld: een hostingaccount beheert een webwinkel en een aparte blog, die elk met een eigen databasegebruiker werken. Als beide gebruikers aan hetzelfde account zijn toegewezen, kan de databasebelasting aan dit account worden toegeschreven. Als een van de vermeldingen ontbreekt of naar het verkeerde account verwijst, is de weergegeven toewijzing niet betrouwbaar voor een klantgerichte evaluatie.

Controleer de Gebruikerstoewijzing Daarom geldt dit niet alleen bij de eerste installatie. Ook na het aanmaken of verplaatsen van databases en gebruikers moet het paneel de toewijzing correct bijhouden. Bij een controle direct na een wijziging moet je rekening houden met de gedocumenteerde doorlooptijd, voordat je op basis van een nog oude stand concludeert dat er sprake is van een blijvende fout.

Van bijzonder belang is het ontbreken van mapping in de modus ‘Abusers’: volgens de fabrikant emuleert deze modus dan de modus ‘Single’. Beperkte klanten delen in de modus ‘Single’ een gemeenschappelijke, beperkte LVE, in plaats van elk in hun eigen klant-LVE te worden beperkt. Het feit dat de Abusers-modus is geactiveerd, bewijst daarom op zich nog niet dat de beoogde beperking per account daadwerkelijk van kracht is.

Vergelijk bij afwijkingen de betrokken databasegebruikers, de bijgewerkte toewijzing en de gekozen bedrijfsmodus met elkaar. Zelfs een correcte toewijzing biedt geen garantie voor volledige isolatie: de databaseservice en de onderliggende hardware worden nog steeds gezamenlijk gebruikt. De toewijzing is een voorwaarde voor een klantspecifieke aansturing, maar geen vervanging voor capaciteitsplanning.

Vergelijking van bedrijfsmodi

De bedrijfsmodus bepaalt of MySQL Governor de databasebelasting alleen in de gaten houdt of dat hij query’s uitvoert in een beperkte omgeving. Niet alleen de drempelwaarden zijn van belang bij deze keuze: ook de toewijzing van de databasegebruikers en de vraag welke klanten één LVE delen, beïnvloeden het effect.

Voor een stand van zaken is het raadzaam om Uit aan: Uit het waargenomen gebruik blijkt welke accounts en tijdsperioden een nadere controle verdienen, zonder dat de Governor daarbij het aantal verzoeken beperkt. Een enkele hoge piekwaarde zegt echter nog niet of een account permanent veel belasting veroorzaakt of juist legitiem onderhoudswerk verricht.

Op Misbruikers Bij beperkte databasequery’s delen deze het LVE-bronnenbudget met andere processen van hetzelfde account, zoals PHP. Een beperking kan daarom niet alleen query’s vertragen: ook de applicatie kan trager reageren als haar processen strijden om dezelfde beperkte bronnen. Omgekeerd kan een reeds bezet PHP-budget de databasewerkzaamheden beïnvloeden.

'Single' is verouderd en vooral relevant voor bestaande configuraties en het gedocumenteerde vervangingsgedrag: meerdere klanten met beperkte rechten delen één omgeving en kunnen daar met elkaar concurreren. Als de dbuser-map ontbreekt, emuleert 'Abusers' dit gedrag; uit de gekozen instelling alleen kan dan niet worden geconcludeerd dat er sprake is van een klantspecifieke beperking. Ook ‘All’ is verouderd en wordt niet standaard aanbevolen voor een nieuwe installatie.

Databaselimieten en tijdsvensters plannen

MySQL Governor maakt onderscheid tussen CPU-gebruik en lees- en schrijf-I/O. De gedocumenteerde CLI geeft de CPU weer in procenten en de I/O in MB/s; voor lezen en schrijven kunnen afzonderlijke waarden worden geconfigureerd. Deze grootheden beschrijven verschillende soorten belasting: een rekenintensieve bewerking hoeft niet tegelijkertijd bijzonder veel naar de opslagmedia te schrijven.

De dwarsbalken current, short, middle en long houden rekening met kortstondig en langdurig gebruik. Overschrijding hiervan leidt, afhankelijk van de bedrijfsmodus en configuratie, tot een beperking. Het gaat hierbij noch om een gegarandeerde doorvoersnelheid, noch om vier onafhankelijke, permanent strikt gehandhaafde prestatiegaranties. Welke beperking daadwerkelijk van kracht is, hangt ook af van de gekozen methode en de LVE-limieten.

Een import illustreert het verschil: als de schrijfbelasting kortstondig toeneemt en daarna weer afneemt, kan dit deel uitmaken van een geplande werkstap. Blijft de belasting gedurende langere tijd hoog, dan legt de import langer beslag op de resources. Om een beslissing te nemen, moet je naast de piekwaarde ook nagaan welke hulpbron erbij betrokken is, hoe lang het proces duurt en of het zich herhaalt.

Laag Drempelwaarden kunnen andere klanten eerder beschermen tegen aanhoudende belasting, maar remmen mogelijk legitieme importen of onderhoudswerkzaamheden af. Hoge drempels bieden meer speelruimte voor dergelijke werkzaamheden, maar laten tegelijkertijd een hogere belasting langer toe. Een onderhoudsvenster of een doelgericht geplande capaciteit kan zinvoller zijn dan een permanente uitzondering.

Stel de Governor-waarden vast in verhouding tot de LVE-limieten en de daadwerkelijk aangeboden tarieven. De aanbevelingen van de fabrikant houden uitdrukkelijk rekening met dit verband; hieruit kunnen geen algemeen geldende productiewaarden worden afgeleid. De waargenomen vraagbelasting, de opvrage-efficiëntie en de aard van de klantopdrachten vormen de basis om drempels na de invoering op gecontroleerde wijze aan te passen.

Inleiding en tarieflimieten voorbereiden

Voorafgaand aan de installatie of upgrade moet er een volledige databaseback-up inclusief de systeemtabellen. Bedenk ook hoe het herstel in geval van nood moet plaatsvinden. De fabrikant wijst erop dat databasepakketten daarbij vanuit CloudLinux-repositories kunnen worden bijgewerkt; het wisselen van pakket is daarom geen onbelangrijk neveneffect dat je pas na de installatie zou moeten controleren.

Controleer vervolgens de combinatie van CloudLinux-editie en -versie, licentie, databasetak, Governor-pakket en configuratiescherm. Het feit dat een bepaalde databaserversie wordt ondersteund, betekent op zich nog niet dat elke combinatie van deze componenten wordt ondersteund. Als de pakketversies of de integratie met het configuratiescherm niet kloppen, moet vóór het uitvoeren van ingrepen worden nagegaan of er daadwerkelijk ondersteuning is.

Begin na de technische voorbereiding met observatie in plaats van onmiddellijke beperking. Vergelijk de gebruikelijke kantooruren met bekende import- en onderhoudsvensters en controleer daarbij of de databasegebruikers aan de juiste hostingaccounts zijn toegewezen. Zonder betrouwbare toewijzing kan uit een ogenschijnlijk lage accountbelasting niet met zekerheid worden geconcludeerd wat de werkelijke behoefte aan resources is.

Leid uit deze inventarisatie een beperkte invoering af: bepaal welke accounts of tarieven hieronder vallen, hoe klachten worden geregistreerd en aan de hand van welke observaties je de instellingen controleert. Vergelijk na de activering de beperkingen met de gebruiksprocessen, in plaats van elke overschrijding direct als wangedrag te beschouwen.

De CloudLinux Manager kan governor-limieten per pakket beheren; voor individuele klanten kunnen afwijkende waarden gelden. Documenteer daarom bij elke wijziging de Herkomst van de limiet: Komt het uit het pakket of is het afzonderlijk ingesteld? Zo kan later worden nagegaan welke klanten door een tariefwijziging worden getroffen en welke uitzondering apart moet worden gecontroleerd.

Huidige belasting en geschiedenis controleren

Voor de diagnose heb je zowel een Momentopname en ook het tijdsverloop. De volgende commando’s worden uitgevoerd in de terminal van de CloudLinux-server, niet in de MySQL-console. Ze dienen ter informatie en wijzigen geen limieten; voor een zinvolle analyse moeten de betreffende tools geïnstalleerd zijn en moeten de relevante gegevens beschikbaar zijn.

Vergelijk opvallende rekeningen met de Gebruikerstoewijzing en de gekozen bedrijfsmodus. Als een databasegebruiker ontbreekt in de toewijzing, kan de zichtbare belasting voor het hostingaccount onvolledig zijn. In de integratiedocumentatie wordt vermeld dat wijzigingen in het toewijzingsbestand binnen vijf minuten worden doorgevoerd; een direct daarna gecontroleerde uitvoer kan daarom nog niet de nieuwe stand weergeven.

Vergelijk vervolgens het tijdstip van een beperking met het waargenomen gebruiksverloop. Een hoge afzonderlijke waarde kan deel uitmaken van een import en is op zichzelf geen bewijs van blijvend overmatig gebruik. De Handleiding voor het lezen van MySQL-Governor-rapporten vormt een aanvulling op de indeling van de weergegeven kengetallen.

Onderscheid maken tussen beperking en oorzaken

Als een website traag wordt, controleer dan eerst of er op dat moment überhaupt een beperking actief was en welke reden daarvoor wordt weergegeven. Breng deze bevinding in verband met de specifieke handeling: een trage afrekening en een gelijktijdig lopende import kunnen met elkaar verband houden, maar dat hoeft niet. Zonder dat de tijdstippen samenvallen, zou het voorbarig zijn om de governor als enige oorzaak aan te wijzen.

In de modus ‘Abusers’ worden beperkte databasequery’s uitgevoerd in het LVE van het toegewezen account. Daar delen ze de Budget met andere processtappen, zoals PHP. Bekijk daarom bij een klacht beide kanten: een taak die veel gebruikmaakt van de database kan met PHP concurreren om systeembronnen; omgekeerd kan reeds bezette LVE-capaciteit de beperkte zoekopdrachten beïnvloeden.

Als de belasting bij een winkel-functie zich herhaalt, onderzoek dan de betreffende query en de Vraagplan in combinatie met geschikte databasestatistieken. Een ontbrekende of ongeschikte index is een mogelijke oorzaak, maar niet de enige. De beperking kan de impact op gedeelde bronnen verminderen; ze corrigeert noch het plan, noch de applicatielogica.

Voor Single en Abusers geeft CloudLinux aan dat beperkingen worden opgeheven zodra het verbruik een minuut lang onder de drempelwaarde is gebleven. Controleer echter wel de daadwerkelijk geconfigureerde Restrict-procedure en het tijdsverloop op je eigen systeem, in plaats van op basis van een korte ontlasting meteen te concluderen dat er sprake is van een permanente oplossing. Een taak die opnieuw wordt gestart, kan later weer een drempel overschrijden.

Limieten bijstellen of de architectuur aanpassen

Begin een aanpassing met de vraag of de waargenomen piek deel uitmaakt van een verwachte taak of regelmatig de werking belemmert. Een geplande import kan mogelijk worden verplaatst naar een onderhoudsvenster. Leg daarbij de duur, de betrokken hulpbron en de gevolgen voor de applicatie vast, voordat je uit een eenmalige piek een permanente tariefwijziging afleidt.

Als het tijdsbestek niet voldoende is, kan een gerichte Uitzondering op het tarief geschikter zijn dan een algemene verhoging voor alle klanten. Leg de aanleiding, de verantwoordelijke contactpersoon en het tijdstip van de herziening vast. Noteer ook of de huidige waarde afkomstig is uit het pakket of individueel is ingesteld: CloudLinux Manager ondersteunt pakketgebonden limieten en individuele afwijkingen.

Controleer na een wijziging gedurende een representatieve periode of het beoogde werk soepeler verloopt en of er elders beperkingen of problemen optreden. Breng daarbij de governor-drempels in verband met de LVE-limieten. Een hogere drempelwaarde maakt in principe een langere periode met een hogere belasting mogelijk; het is echter geen garantie voor de doorvoer en evenmin een toezegging voor bepaalde responstijden.

Een andere aanpassingsmogelijkheid is de Oorzaak verhelpen: Door query-optimalisatie, geschikte indexen of caching kan terugkerend werk worden verminderd, in plaats van alleen de gevolgen ervan te beperken. Verbindingslimieten aan de kant van de database beperken daarentegen het gelijktijdige gebruik en vervangen niet automatisch de CPU- en I/O-regeling van de governor.

Als de eisen van een klant op de lange termijn sterk afwijken van die van shared hosting, kan het zinvol zijn om een eigen database-instantie of een eigen server te gebruiken. Dit verschuift de beslissing echter van individuele drempels naar de planning van capaciteit, onderhoud en exploitatie. Ook een dergelijke scheiding mag niet zonder meer worden voorgesteld als garantie voor volledige isolatie of vaste responstijden.