MySQL Governor: Begränsa databasresurserna för enskilda webbhotellskunder

Vad MySQL Governor begränsar

MySQL Governor är en CloudLinux-komponent för delade webbhotellsservrar, inte en allmän funktion i MySQL. Den mäter databasbelastningen utifrån tilldelade användare och kan, när tröskelvärdena överskrids, begränsa sökningar via Lightweight Virtual Environments, förkortat LVE. På så sätt kan belastningen på enskilda webbhotellskonton analyseras mer nyanserat än om man enbart tittar på databasserverens totala belastning.

I fokus står CPU och hårddisk-I/O: Guvernören beaktar beräkningsbelastning samt läs- och skrivaktivitet. En hög belastning kan till exempel uppstå till följd av en import eller en ofta utförd butiksförfrågan. Genom att koppla belastningen till ett konto blir den synlig; huruvida den är rimlig för den aktuella transaktionen måste sedan bedömas utifrån sammanhanget.

En databasbegränsning för dessa resurser är inte en lagringskvot. En stor databas som sällan används kan orsaka liten löpande CPU- och I/O-belastning; omvänt kan en liten databas belastas kraftigt av många resurskrävande åtkomstförfrågningar. Även anslutningsbegränsningar svarar på en annan fråga: de begränsar åtkomst, men ersätter inte automatiskt styrningen av CPU och I/O.

Om en förfrågan begränsas betyder det inte nödvändigtvis att den är felaktig. Begränsningen kan skydda andra konton mot hög belastning, men samtidigt bromsa en legitim applikation. Detta innebär inte att svarstiderna är garanterade, eftersom databastjänsten, hårdvaran och övriga applikationskomponenter förblir delar av systemet som delas av flera användare.

För att förstå samspelet mellan konton, belastning och LVE ger den kompletterande översikten över Begränsning av databasbelastningen med CloudLinux MySQL Governor ytterligare en ingång. Den faktiskt installerade miljön och de inställningar som gäller där är avgörande för den konkreta konfigurationen.

Kontrollera version och kompatibilitet

Innan du planerar databasgränserna bör du först kontrollera Utgåva och licens. Enligt tillverkaren innehåller CloudLinux OS Admin inte MySQL Governor. Ett CloudLinux-system i sig är därför inget bevis på att komponenten är tillgänglig, licensierad och installerad på servern för den valda utgåvan.

Därefter tittar du på kombinationen av CloudLinux-version, Governor-paket och databasserver. MySQL och MariaDB är separata utvecklingsgrenar: Att en viss version av MySQL stöds innebär inte att en lika gammal version av MariaDB fungerar under samma förhållanden. Även den använda kontrollpanelen och dess integration ingår i kontrollen.

Minimikraven visar varför ett generellt godkännande inte räcker: För MySQL 8.4 anger CloudLinux att minst MySQL Governor 1.2-129 krävs. MariaDB 11.4 kräver minst version 1.2-122 av Governor och stöds inte för CloudLinux OS 7 enligt tillverkarens dokumentation. Dessa uppgifter gäller de nämnda grenarna och ersätter inte en kontroll av övriga kombinationer.

Som installationsmiljöer nämner tillverkaren bland annat cPanel, Plesk, DirectAdmin, ISPmanager och InterWorx samt servrar utan kontrollpanel. Om du använder en annan kontrollpanel eller en egenintegrerad sådan bör du separat klargöra det konkreta stödet och framför allt hur användare tilldelas. Att en databasversion anges i listan innebär inte att den garanteras fungera med alla kombinationer av kontrollpaneler och operativsystem.

Dokumentera de befintliga versionerna och paketen innan du gör någon ändring och jämför dem med dokumentationen för den planerade målkonfigurationen. På så sätt kan du avgöra om det först krävs ett komponentbyte, istället för att enbart utifrån databasnamnet anse en befintlig installation som kompatibel.

Tilldela databasanvändare webbhotellskonton

För att belastningen ska kunna tilldelas en webbhotellskund måste kopplingen mellan databasanvändare och webbhotellskonton stämma. Vid en panelintegration används vanligtvis filen /etc/container/dbuser-map underhålls. Guvernören inför ändringar i denna tilldelning enligt integrationsdokumentationen inom fem minuter.

Ett exempel: Ett webbhotellskonto driver en webbutik och en separat blogg, som båda använder varsin databasanvändare. Om båda användarna är kopplade till samma konto kan databasbelastningen registreras för just detta konto. Om någon av posterna saknas eller pekar på fel konto är den visade tilldelningen inte tillförlitlig för en kundrelaterad utvärdering.

Kontrollera Användartilldelning Därför gäller detta inte bara vid den första installationen. Även efter att databaser och användare har skapats eller flyttats måste panelen uppdatera tilldelningen korrekt. Vid en kontroll direkt efter en ändring måste du ta hänsyn till den dokumenterade överföringstiden innan du drar slutsatsen att det rör sig om ett bestående fel utifrån en fortfarande gammal status.

Det är särskilt viktigt att notera att mappningen saknas i läget ”Abusers”: Enligt tillverkaren emulerar detta läge då läget ”Single”. Begränsade kunder delar i läget ”Single” en gemensam begränsad LVE, istället för att var och en begränsas i sin egen kund-LVE. Att Abusers-läget är aktiverat är därför i sig inte tillräckligt för att bevisa att den avsedda konto-specifika begränsningen faktiskt gäller.

Vid avvikelser bör du jämföra de berörda databasanvändarna, den uppdaterade tilldelningen och det valda driftsläget med varandra. Även en korrekt mappning garanterar inte fullständig isolering: databastjänsten och den underliggande hårdvaran fortsätter att delas. Tilldelningen är en förutsättning för kundspecifik styrning, inte en ersättning för kapacitetsplanering.

Jämförelse av driftslägen

Driftläget avgör om MySQL Governor endast övervakar databasbelastningen eller utför sökningar i en begränsad miljö. Det är inte bara tröskelvärdena som är avgörande för valet: även tilldelningen av databasanvändare och frågan om vilka kunder som delar en LVE påverkar resultatet.

För att göra en lägesbedömning lämpar sig Av an: Den observerade användningen visar vilka konton och tidsperioder som förtjänar en närmare granskning, utan att guvernören behöver begränsa förfrågningarna. Ett enskilt högt momentvärde säger dock inte nödvändigtvis om ett konto genererar en stor belastning över en längre tid eller om det just nu utför ett legitimt underhållsarbete.

Med Missbrukare Begränsade databasfrågor delar LVE-resursbudgeten med andra processer på samma konto, till exempel PHP. En begränsning kan därför inte bara förlänga frågorna: även applikationen kan reagera långsammare om dess processer konkurrerar om samma begränsade resurser. Omvänt kan en redan upptagen PHP-budget påverka databasarbetet.

”Single” är föråldrat och relevant främst för befintliga konfigurationer samt det dokumenterade ersättningsbeteendet: Flera kunder med begränsningar delar en miljö och kan där konkurrera med varandra. Om dbuser-map saknas emulerar Abusers detta beteende; enbart utifrån den valda inställningen går det då inte att dra slutsatsen att det rör sig om en kundspecifik begränsning. Även inställningen ”All” är föråldrad och rekommenderas inte vid en nyinstallation.

Planera databasbegränsningar och tidsfönster

MySQL Governor skiljer mellan CPU-användning samt läs- och skriv-I/O. Den dokumenterade kommandoradsgränssnittet visar CPU i procent och I/O i MB/s; separata värden kan konfigureras för läsning och skrivning. Dessa storheter beskriver olika typer av belastning: En beräkningsintensiv process behöver inte nödvändigtvis skriva särskilt mycket till lagringsmediet.

Trösklarna kort, medellång och lång beaktar både kortvarig och mer långvarig användning. Om dessa värden överskrids utlöses en begränsning beroende på driftsläge och konfiguration. De utgör varken en garanterad genomströmning eller fyra oberoende av varandra permanent och strikt tillämpade prestandagarantier. Vilken begränsning som faktiskt träder i kraft beror också på den valda metoden och LVE-gränserna.

En import tydliggör skillnaden: Om skrivbelastningen ökar kortvarigt och sedan sjunker igen kan det vara en del av en planerad arbetsprocess. Om den förblir hög under en längre tid tar importen upp resurser under en längre tid. För att fatta ett beslut bör du, förutom toppvärdet, kontrollera vilken resurs som påverkas, hur länge processen pågår och om den upprepas.

Låg Tröskelvärden kan skydda andra kunder mot långvarig belastning i ett tidigt skede, men kan samtidigt hämma legitima importtransaktioner eller underhållsarbeten. Höga tröskelvärden ger större handlingsutrymme för sådana arbeten, men tillåter samtidigt en högre belastning under en längre tid. Ett underhållsfönster eller en specifikt planerad kapacitet kan vara ett bättre alternativ än ett permanent undantag.

Planera regulatorvärdena i förhållande till LVE-gränserna och de faktiskt erbjudna tarifferna. Tillverkarens rekommendationer beaktar uttryckligen detta samband; generellt giltiga produktionsvärden kan inte härledas därifrån. Observerad förfrågningsbelastning, förfrågningseffektivitet och typen av kunduppdrag utgör grunden för att på ett kontrollerat sätt justera tröskelvärdena efter införandet.

Förbereda införandet och prisgränserna

Innan installation eller uppgradering måste man fullständig databasbackup inklusive systemtabellerna. Planera också hur återställningen ska gå till om det skulle behövas. Tillverkaren påpekar att databaspaket kan uppdateras från CloudLinux-repositorier; ett byte av paket är därför inte en obetydlig bieffekt som du bör kontrollera först efter installationen.

Kontrollera därefter kombinationen av CloudLinux-utgåva och -version, licens, databasgren, Governor-paket och kontrollpanel. Att en databasversion stöds innebär inte i sig att varje kombination av dessa komponenter stöds. Om paketversionerna eller panelintegrationen inte stämmer måste det konkreta stödet klargöras innan någon åtgärd vidtas.

Efter den tekniska förberedelsen bör du börja med övervakning istället för omedelbar begränsning. Jämför typiska öppettider med kända import- och underhållsfönster och kontrollera samtidigt om databasanvändarna är tilldelade rätt hostingkonton. Utan en tillförlitlig tilldelning går det inte att med säkerhet dra slutsatser om det faktiska resursbehovet utifrån en till synes låg kontobelastning.

Utifrån denna kartläggning ska du utarbeta en begränsad införandeplan: Fastställ vilka konton eller prisplaner som ska omfattas, hur klagomål ska registreras och utifrån vilka observationer du ska granska inställningarna. Efter aktiveringen ska du jämföra begränsningarna med användarnas aktiviteter, istället för att omedelbart betrakta varje överskridande som ett felaktigt beteende.

CloudLinux Manager kan hantera Governor-gränser på paketnivå; avvikande värden kan gälla för enskilda kunder. Dokumentera därför vid varje ändring Gränsens ursprung: Kommer det från paketet eller har det angetts individuellt? På så sätt går det senare att se vilka kunder som berörs av en prisändring och vilka undantag som måste granskas separat.

Kontrollera aktuell belastning och historik

För att ställa diagnosen behöver du både en Ögonblicksbild samt tidsförloppet. Följande kommandon körs i terminalen på CloudLinux-servern, inte i MySQL-konsolen. De är avsedda för granskning och ändrar inga gränsvärden; för en meningsfull utvärdering måste de aktuella verktygen vara installerade och relevanta data vara tillgängliga.

Jämför liknande konton med Användartilldelning och det valda driftsläget. Om en databasanvändare saknas i mappningen kan den synliga belastningen för webbhotellskontot vara ofullständig. I integrationsdokumentationen anges att ändringar i mappningsfilen överförs inom fem minuter; ett resultat som kontrolleras omedelbart därefter kan därför ännu inte återspegla den nya statusen.

Jämför därefter tidpunkten för en begränsning med den observerade användningsprocessen. Ett högt enskilt värde kan ingå i en import och är i sig inte ett bevis på varaktig överanvändning. Den Anvisningar för hur man läser MySQL-Governor-rapporter kompletterar tolkningen av de visade nyckeltalen.

Att skilja mellan begränsning och orsaker

Om en webbplats blir långsam, kontrollera först om det överhuvudtaget fanns någon begränsning aktiv vid den aktuella tidpunkten och vilken orsak som anges. Koppla detta resultat till den specifika händelsen: En långsam utcheckning och en import som pågår samtidigt kan hänga ihop, men det behöver inte vara så. Utan tidsmässig överensstämmelse vore det förhastat att fastställa att Governor är den enda orsaken.

I läget ”Abusers” utförs begränsade databasfrågor i LVE för det tilldelade kontot. Där delar de Resursbudget med andra kontoprocesser, till exempel PHP. Beakta därför båda sidor vid ett klagomål: En databasintensiv uppgift kan konkurrera om resurser med PHP; omvänt kan redan upptagen LVE-kapacitet påverka de begränsade sökningarna.

Om belastningen upprepas i samband med en butiksfunktion, undersök den aktuella frågan och dess Frågeplan tillsammans med lämplig databasstatistik. En saknad eller olämplig index är en möjlig orsak, men inte den enda. Begränsningen kan minska påverkan på delade resurser; den korrigerar varken planen eller applikationslogiken.

För Single och Abusers anger CloudLinux att begränsningarna upphävs efter att användningen har legat under tröskelvärdet i en minut. Kontrollera dock den faktiskt konfigurerade begränsningsproceduren och tidsförloppet på ditt eget system, istället för att omedelbart dra slutsatsen att det rör sig om en permanent lösning utifrån en kortvarig avlastning. En uppgift som startas om kan senare återigen överskrida tröskelvärdet.

Justera gränserna eller ändra arkitekturen

Inled en justering med att fråga dig om den observerade toppen hör till en förväntad uppgift eller om den regelbundet påverkar driften negativt. En planerad import kan eventuellt flyttas till ett underhållsfönster. Registrera då varaktighet, berörd resurs och påverkan på applikationen innan du drar slutsatsen att en enstaka topp innebär en permanent prisändring.

Om tidsramen inte räcker till kan en riktad Undantag från avtalet kan vara lämpligare än en generell höjning för alla kunder. Dokumentera anledningen, den ansvariga kontaktpersonen och tidpunkten för den nya granskningen. Notera även om det tidigare värdet härrör från paketet eller har ställts in individuellt: CloudLinux Manager stöder paketbaserade gränsvärden och individuella avvikelser.

Efter en ändring bör du under en representativ tidsperiod kontrollera om det avsedda arbetet hanteras bättre och om det uppstår begränsningar eller problem på andra ställen. Sätt då governor-tröskelvärdena i relation till LVE-gränserna. Ett högre tröskelvärde möjliggör potentiellt en högre belastning under en längre tid; det är varken en garanti för genomströmning eller ett löfte om specifika svarstider.

En annan justeringsmöjlighet är Åtgärdande av orsaken: Optimering av sökningar, lämpliga index eller cachelagring kan minska återkommande arbetsuppgifter, istället för att bara begränsa deras effekter. Anslutningsbegränsningar på databassidan begränsar däremot samtidiga åtkomstförsök och ersätter inte automatiskt guvernörens CPU- och I/O-styrning.

Om en kunds krav på sikt avviker kraftigt från vad som gäller för delad hosting kan det vara lämpligt att ha en egen databasinstans eller en egen server. Detta innebär dock att beslutet inte längre handlar om enskilda tröskelvärden, utan om planering av kapacitet, underhåll och drift. En sådan uppdelning bör inte heller generellt framställas som en garanti för fullständig isolering eller fasta svarstider.