MySQL Governor: Begrænsning af databaseressourcer for individuelle hostingkunder

Hvad MySQL Governor begrænser

MySQL Governor er en CloudLinux-komponent til shared hosting-servere, ikke en generel funktion i MySQL. Den registrerer databasebelastningen ud fra de tilknyttede brugere og kan, hvis tærskelværdierne overskrides, begrænse forespørgsler via Lightweight Virtual Environments, forkortet LVE. På denne måde kan belastningen på de enkelte hostingkonti vurderes mere nuanceret end blot den samlede belastning af databaseserveren.

I centrum står CPU og harddisk-I/O: Governor tager højde for regnebelastning samt læse- og skriveaktivitet. En høj belastning kan f.eks. skyldes en import eller en hyppigt udført forespørgsel i webshoppen. Tilknytningen til en konto gør denne belastning synlig; om den er rimelig i forhold til den pågældende proces, skal derefter vurderes ud fra sammenhængen.

En databasebegrænsning for disse ressourcer er ikke en lagerpladsquota. En stor database, der sjældent bruges, kan medføre en lav løbende CPU- og I/O-belastning; omvendt kan en lille database blive stærkt belastet af mange ressourcekrævende adgangsforespørgsler. Forbindelsesbegrænsninger besvarer også et andet spørgsmål: De begrænser adgang, men erstatter ikke automatisk styringen af CPU og I/O.

Hvis en forespørgsel begrænses, betyder det ikke nødvendigvis, at den er fejlbehæftet. Begrænsningen kan beskytte andre konti mod stor belastning, men samtidig gøre en legitim anvendelse langsommere. Der følger ikke nogen garanterede svartider heraf, da databasetjenesten, hardwaren og andre applikationskomponenter fortsat er fælles dele af systemet.

For at få et overblik over samspillet mellem konti, debiteringer og LVE giver det supplerende overblik over Begrænsning af belastningen på databasen med CloudLinux MySQL Governor en yderligere indgang. Det afgørende for den konkrete opsætning er stadig det faktisk installerede miljø og de indstillinger, der gælder der.

Kontroller udgave og kompatibilitet

Inden du planlægger databasegrænserne, skal du først kontrollere Udgave og licens. Ifølge producenten indeholder CloudLinux OS Admin ikke MySQL Governor. Et CloudLinux-system i sig selv er derfor ikke et bevis på, at komponenten er tilgængelig, licenseret og installeret på serveren for den valgte udgave.

Derefter skal du se på kombinationen af CloudLinux-version, Governor-pakke og databaseserver. MySQL og MariaDB er her to separate udviklingsgrene: At en bestemt MySQL-version understøttes, betyder ikke, at en MariaDB-version af samme alder fungerer under de samme betingelser. Også det anvendte kontrolpanel og dets integration skal indgå i vurderingen.

Minimumsversionerne viser, hvorfor en generel godkendelse ikke er tilstrækkelig: For MySQL 8.4 angiver CloudLinux som minimum MySQL Governor 1.2-129. MariaDB 11.4 kræver mindst version 1.2-122 af Governor og understøttes ikke til CloudLinux OS 7 i producentens dokumentation. Disse oplysninger gælder de nævnte grene og erstatter ikke en kontrol af de øvrige kombinationer.

Som installationsmiljøer nævner producenten blandt andet cPanel, Plesk, DirectAdmin, ISPmanager og InterWorx samt servere uden kontrolpanel. Hvis du bruger et andet eller selvintegreret panel, bør du afklare den konkrete support og især brugertildelingen separat. En angivet databaseversion er ikke en garanti for kompatibilitet med alle kombinationer af kontrolpaneler og operativsystemer.

Notér de eksisterende versioner og pakker, inden du foretager ændringer, og sammenlign dem med dokumentationen for den planlagte målkonfiguration. På den måde kan du se, om det først er nødvendigt at udskifte en komponent, i stedet for blot at betragte en eksisterende installation som kompatibel ud fra databasenavnet alene.

Tildele databasebrugere hostingkonti

For at belastningen kan tilknyttes en hostingkunde, skal der være overensstemmelse mellem databasebrugere og hostingkonti. Ved en panelintegration anvendes der normalt filen /etc/container/dbuser-map vedligeholdes. Guvernøren overfører ændringer til denne tildeling i henhold til integrationsdokumentationen inden for fem minutter.

Et eksempel: En hostingkonto driver en webshop og en separat blog, som hver især bruger deres egen databasebruger. Hvis begge brugere er tilknyttet den samme konto, kan databasebelastningen registreres i henhold til denne konto. Mangler en af oplysningerne, eller peger den på den forkerte konto, er den viste tilknytning ikke pålidelig til en kundebaseret vurdering.

Tjek Brugertildeling Derfor gælder det ikke kun ved den første installation. Også efter oprettelse eller flytning af databaser og brugere skal panelet ajourføre tilknytningen korrekt. Ved en kontrol umiddelbart efter en ændring skal du tage højde for den dokumenterede overførselstid, før du ud fra en stadig gammel status konkluderer, at der er tale om en vedvarende fejl.

Det er især vigtigt at bemærke, at der mangler en kortlægning i Abusers-tilstanden: Ifølge producenten emulerer denne tilstand i så fald Single. Begrænsede kunder deler i Single et fælles, begrænset LVE i stedet for hver især at være begrænset til deres eget kunde-LVE. En aktiveret »Abusers«-tilstand alene er derfor ikke i sig selv bevis for, at den tilsigtede konto-specifikke begrænsning rent faktisk træder i kraft.

I tilfælde af uregelmæssigheder skal du sammenholde de berørte databasebrugere, den vedligeholdte tildeling og den valgte driftsform. Selv en korrekt tilknytning garanterer ikke fuldstændig isolering: Databasetjenesten og den underliggende hardware deles fortsat. Tilknytningen er en forudsætning for kundespecifik styring, ikke en erstatning for kapacitetsplanlægning.

Sammenligning af driftsformer

Driftsmodusen afgør, om MySQL Governor blot overvåger databasebelastningen eller udfører forespørgsler i et afgrænset miljø. Det er ikke kun tærskelværdierne, der er afgørende for valget: Også tildelingen af databasebrugere og spørgsmålet om, hvilke kunder der deler en LVE, har indflydelse på effekten.

Til en statusopgørelse er det oplagt at Fra an: Den observerede brug viser, hvilke konti og tidsperioder der fortjener en nærmere undersøgelse, uden at guvernøren begrænser forespørgslerne. En enkelt høj øjebliksværdi siger dog ikke nødvendigvis noget om, hvorvidt en konto genererer en vedvarende stor belastning, eller om der netop udføres et legitimt vedligeholdelsesarbejde.

Med Misbrugere Begrænsede databaseforespørgsler deler LVE-ressourcebudgettet med andre processer på samme konto, f.eks. PHP. En begrænsning kan derfor ikke kun forlænge forespørgslerne: Applikationen kan også reagere langsommere, hvis dens processer konkurrerer om de samme begrænsede ressourcer. Omvendt kan et allerede optaget PHP-budget påvirke databasearbejdet.

»Single« er forældet og er især relevant for eksisterende konfigurationer samt den dokumenterede erstatningsadfærd: Flere kunder med begrænsninger deler et miljø og kan konkurrere med hinanden der. Mangler dbuser-map, emulerer Abusers denne adfærd; ud fra den valgte indstilling alene kan man derfor ikke konkludere, at der er tale om en kundespecifik begrænsning. Også »All« er forældet og anbefales ikke til en nyinstallation.

Planlægning af databasebegrænsninger og tidsvinduer

MySQL Governor skelner mellem CPU-udnyttelse samt læse- og skrive-I/O. Den dokumenterede CLI viser CPU i procent og I/O i MB/s; der kan konfigureres separate værdier for læsning og skrivning. Disse størrelser beskriver forskellige belastninger: En beregningsintensiv proces behøver ikke nødvendigvis at skrive særlig meget til datamediet.

Tærsklerne kort, mellemlang og lang tager højde for kortvarig og længerevarende brug. Overskridelse af disse værdier udløser en begrænsning afhængigt af driftsform og konfiguration. De udgør hverken en garanteret gennemstrømning eller fire uafhængige, permanent og strengt håndhævede ydeevneløfter. Hvilken begrænsning der rent faktisk træder i kraft, afhænger også af den valgte metode og LVE-grænserne.

En import illustrerer forskellen: Hvis skrivebelastningen stiger kortvarigt og derefter falder igen, kan det være en del af en planlagt arbejdsopgave. Forbliver den høj i længere tid, belaster importen ressourcerne i længere tid. Når du skal træffe en beslutning, bør du ud over spidsværdien også undersøge, hvilken ressource der er berørt, hvor længe processen varer, og om den gentager sig.

Lav Udløsningstærskler kan beskytte andre kunder mod vedvarende belastning på et tidligere tidspunkt, men kan muligvis hæmme legitime importtransaktioner eller vedligeholdelsesopgaver. Høje tærskelværdier giver større spillerum til sådanne opgaver, men tillader samtidig en højere belastning i længere tid. Et vedligeholdelsesvindue eller en målrettet planlagt kapacitet kan være mere hensigtsmæssigt end en permanent undtagelse.

Planlæg guvernørværdierne i forhold til LVE-grænserne og de faktisk tilbudte takster. Producentens anbefalinger tager udtrykkeligt højde for denne sammenhæng; der kan ikke udledes generelt gældende produktionsværdier heraf. Den observerede forespørgselsbelastning, forespørgsels effektivitet og typen af kundeopgaver danner grundlaget for en kontrolleret justering af tærskelværdierne efter implementeringen.

Forberedelse af introduktion og takstgrænser

Før installation eller opgradering skal man fuldstændig sikkerhedskopi af databasen herunder systemtabellerne. Planlæg også, hvordan genoprettelsen skal foregå, hvis det bliver nødvendigt. Producenten gør opmærksom på, at databasepakker kan opdateres fra CloudLinux-repositorier; et skift af pakke er derfor ikke en ubetydelig bivirkning, som du først bør tjekke efter installationen.

Kontroller derefter kombinationen af CloudLinux-udgave og -version, licens, database-gren, Governor-pakke og kontrolpanel. En understøttet databaseversion er i sig selv ikke bevis for, at enhver kombination af disse komponenter understøttes. Hvis pakkeversionerne eller panelintegrationen ikke stemmer overens, skal den konkrete understøttelse afklares, inden der foretages ændringer.

Efter den tekniske forberedelse skal du starte med overvågning i stedet for straks at begrænse belastningen. Sammenlign typiske åbningstider med kendte import- og vedligeholdelsesvinduer, og kontroller samtidig, om databasebrugerne er tildelt de rigtige hostingkonti. Uden en pålidelig tildeling kan man ikke med sikkerhed udlede det faktiske ressourcebehov ud fra en tilsyneladende lav kontabelastning.

Ud fra denne statusopgørelse skal du udarbejde en begrænset implementering: Fastlæg, hvilke konti eller takster der skal være omfattet, hvordan klager skal registreres, og på baggrund af hvilke observationer du vil kontrollere indstillingerne. Efter aktiveringen skal du sammenholde begrænsningerne med de faktiske transaktioner i stedet for straks at betragte enhver overskridelse som en fejl.

CloudLinux Manager kan administrere governor-grænser på pakkeniveau; der kan gælde afvigende værdier for enkelte kunder. Dokumenter derfor ved hver ændring Begrænsningens oprindelse: Stammer det fra pakken, eller er det indstillet individuelt? På den måde kan man senere se, hvilke kunder der berøres af en takstændring, og hvilke undtagelser der skal kontrolleres separat.

Kontroller den aktuelle belastning og historikken

For at stille diagnosen skal du både have en Øjebliksbillede samt tidsforløbet. De følgende kommandoer udføres i terminalen på CloudLinux-serveren, ikke i MySQL-konsollen. De tjener til oversigtsformål og ændrer ikke nogen grænser; for at kunne foretage en meningsfuld analyse skal de pågældende værktøjer være installeret, og de relevante data skal være tilgængelige.

Lignende mistænkelige konti med den Brugertildeling og den valgte driftsform. Hvis en databasebruger mangler i mappingen, kan den synlige belastning for hostingkontoen være ufuldstændig. Integrationsdokumentationen angiver, at ændringer i tilordningsfilen overføres inden for fem minutter; et output, der kontrolleres umiddelbart derefter, kan derfor endnu ikke vise den nye status.

Sammenlign derefter tidspunktet for en begrænsning med den observerede anvendelsesproces. En høj enkeltværdi kan være en del af en import og er i sig selv ikke bevis på vedvarende overdreven brug. Den Vejledning i at læse MySQL-Governor-rapporter supplerer klassificeringen af de viste nøgletal.

At skelne mellem begrænsninger og årsager

Hvis et websted bliver langsomt, skal du først kontrollere, om der overhovedet var en begrænsning aktiv på det pågældende tidspunkt, og hvilken årsag der vises. Knyt denne konstatering til den konkrete hændelse: En langsom checkout og en import, der kører samtidig, kan hænge sammen, men det er ikke nødvendigvis tilfældet. Uden en tidsmæssig sammenhæng ville det være forhastet at udpege Governor som den eneste årsag.

I tilstanden »Abusers« udføres begrænsede databaseforespørgsler i LVE for den tilknyttede konto. Der deler de Budget for ressourcer med andre procesløsninger, f.eks. PHP. Man bør derfor se på begge sider, når der opstår et problem: En databaseintensiv opgave kan konkurrere med PHP om ressourcerne; omvendt kan LVE-kapacitet, der allerede er optaget, påvirke de begrænsede forespørgsler.

Hvis belastningen gentager sig i forbindelse med en butiksfunktion, skal du undersøge den pågældende forespørgsel og dens Forespørgselsplan sammen med relevante databasestatistikker. Et manglende eller uegnet indeks er en mulig årsag, men ikke den eneste. Begrænsningen kan mindske påvirkningen på de fælles ressourcer; den korrigerer hverken planen eller applikationslogikken.

For Single og Abusers angiver CloudLinux, at begrænsningerne ophæves, når forbruget har ligget under tærskelværdierne i et minut. Du bør dog alligevel kontrollere den faktisk konfigurerede Restrict-procedure og tidsforløbet på dit eget system, i stedet for straks at konkludere, at der er tale om en permanent løsning, blot fordi der kortvarigt har været en aflastning. En opgave, der genstartes, kan senere igen overskride en tærskelværdi.

Justere grænserne eller ændre arkitekturen

Start en tilpasning med at undersøge, om den observerede spidsbelastning hører til en forventet opgave, eller om den regelmæssigt forstyrrer driften. En planlagt import kan muligvis flyttes til et vedligeholdelsesvindue. Registrer i den forbindelse varighed, berørte ressourcer og konsekvenser for applikationen, inden du ud fra en enkelt spidsbelastning konkluderer, at der er behov for en permanent takstændring.

Hvis tidsrammen ikke er tilstrækkelig, kan en målrettet Undtagelse fra taksten vil være mere hensigtsmæssigt end en generel forhøjelse for alle kunder. Dokumentér årsagen, den ansvarlige kontaktperson og tidspunktet for den nye gennemgang. Notér også, om den hidtidige værdi stammer fra pakken eller er blevet indstillet individuelt: CloudLinux Manager understøtter pakkebaserede grænser og individuelle afvigelser.

Efter en ændring skal du over en repræsentativ periode kontrollere, om det påtænkte arbejde kører bedre, og om der opstår begrænsninger eller problemer andre steder. Sæt i den forbindelse governor-tærsklerne i forhold til LVE-grænserne. En højere tærskelværdi tillader potentielt en større belastning i længere tid; den er hverken en garanti for gennemstrømning eller en løfte om bestemte svartider.

En anden justeringsmulighed er Afhjælpning af årsagen: Optimering af forespørgsler, passende indekser eller caching kan reducere gentagne opgaver i stedet for blot at begrænse deres indvirkning. Forbindelsesbegrænsninger på databasesiden begrænser derimod samtidige adgangsforespørgsler og erstatter ikke automatisk Governorens CPU- og I/O-styring.

Hvis en kundes krav på lang sigt afviger markant fra kravene til shared hosting, kan det være en god idé at have sin egen databaseinstans eller sin egen server. Det flytter dog beslutningen fra enkelte tærskler til planlægning af kapacitet, vedligeholdelse og drift. En sådan adskillelse bør heller ikke generelt fremstilles som en garanti for fuldstændig isolation eller faste responstider.