Hoppa till innehåll 
CloudLinux MySQL Governor begränsar databasbelastningen per konto och fördelar den rättvist, så att enskilda sökningar inte saktar ner hela webbhotellet. Jag använder MySQL Governor, för att i realtid övervaka CPU, READ och WRITE per användare och automatiskt begränsa användningen vid överskridanden.
Centrala punkter
- Per konto istället för globala gränser
- CPU/LÄSNING/SKRIVNING styra separat
- Lägen Endast övervakning och missbruk li>LVE som en andra skyddsnivå
- CLI-verktyg för kontroll
Varför enskilda sökfrågor saktar ner allt
I miljöer med delad hosting skapas oftast endast ett fåtal Frågor den största belastningen, inte databasernas storlek. Jag ser ofta att en felaktig sökfråga eller ett plugin med hög I/O plötsligt tar upp all CPU-tid och att latensen märkbart ökar för andra användare. Det är just här som guvernör eftersom den visar belastningen per användare och inte bara tar hänsyn till det totala genomsnittet. På så sätt förhindrar jag att en „bullrig granne“ sätter käppar i hjulet för alla andra projekt, trots att deras arbetsbelastning är normal. Med tydliga gränsvärden och en rättvis fördelning ser jag till att svarstiderna blir förutsägbara och tar bort grunden för överdriven belastning.
Så här fungerar MySQL Governor i vardagen
Jag börjar ofta i Monitor-only-läget för att mäta den faktiska användningen utan att ingripa. Därefter aktiverar jag Abusen-läget, som automatiskt flyttar konton med överdriven aktivitet till en begränsad miljö och därmed omedelbart begränsar effekten. Mätningen baseras på Tråd-Statistik per MySQL/MariaDB-anslutning, vilket gör det möjligt att följa CPU-användning samt läs- och skrivandelar per användare. Vid ihållande överbelastning aktiveras dessutom den tilldelade LVE, vilket ytterligare bromsar processerna för dessa konton. Denna tvåstegsprocess förhindrar eskaleringar, dämpar toppar och skyddar pålitligt projekt som inte är inblandade.
Välj gränsvärden och tidsfönster på ett lämpligt sätt
Jag sätter gränser för flera Intervaller, så att jag kan tolerera kortvariga toppar men på ett tillförlitligt sätt stoppa långvarig överbelastning. Korta tidsfönster får ligga högre, medellånga måttligt, långa klart strängare, och de bör ligga under de globala LVE-gränserna. CPU mäter jag som procentandel per Kärnan; vid åtta kärnor motsvarar 100% en full kärna, vilket gör att fördelningen och rättvisan förblir transparenta. Jag utvärderar READ och WRITE utifrån verklig disk-I/O, det vill säga utan cacheträffar, så att jag kan se den faktiska belastningen på lagringsenheten. För en ren helhetskonfiguration utgår jag från beprövade LVE-regler och detaljer som i Konfigurera LVE-gränser på rätt sätt beskriven.
Planera intervaller efter tid på dygnet och profiler
Jag lämnar gärna profiler som varierar beroende på tid på dygnet: Under högtrafikperioden tillåter jag något större korta intervall för att hantera legitima trafiktoppar (t.ex. snabba rea-kampanjer i webbutiken). Under kvälls- och nattimmarna drar jag framför allt långa intervall striktare, så att långvariga jobb inte obemärkt utnyttjar hårddisken till max. För batchfönster definierar jag egna profiler med något mer WRITE, men begränsad CPU, så att importerna går snabbt men inte tar över allt. Det är viktigt att komma ihåg: Jag ändrar aldrig alla inställningar samtidigt. Först justerar jag CPU-användningen, observerar, och sedan READ/WRITE. Varje ändring får en tydlig observationsperiod så att orsak och verkan tydligt kan skiljas åt.
CLI-verktyg och snabb felsökning
Jag analyserar misstänkta konton med dbtop i realtid, uppdatera gränsvärden med dbctl och granska historiska loggar via lveinfo –dbgov. Dessa verktyg ger mig inom några sekunder relevanta uppgifter om toppvärden, långvariga sökningar och antalet anslutningar per användare. På så sätt kan jag se om framför allt CPU eller om det är I/O-begränsningar, om anslutningarna blir för många eller om enskilda tabeller orsakar köer i frågorna. Utifrån mönstren fastställer jag anpassade tröskelvärden för varje intervall och testar först ändringarna i ”Monitor-only”-läge. Först när kurvorna visar en rimlig nedgång aktiverar jag begränsningen permanent.
| Verktyg | Syfte | Exempel |
|---|---|---|
| dbtop | Live-vy per användare/tråd | dbtop – efter användare |
| dbctl | Sätta gränser och styra lägen | dbctl set userX cpu=120 read=8 write=6 |
| lveinfo –dbgov | Kontrollera historik och överträdelser | lveinfo –dbgov –id userX –period 1h |
Felsökning: typiska mönster och snabba åtgärder
När CPU När jag granskar ett konto upptäcker jag ofta mönster som SELECT *, saknade WHERE-klausuler, komplexa ORDER BY-satser med stora resultatuppsättningar eller N+1-frågor från ORM:er. När det gäller I/O ser jag fullskanningar utan lämpliga index, upprepade LIKE ‚%…%‘ eller JOIN-satser på icke-indexerade kolumner. Mitt tillvägagångssätt: identifiera berörda tabeller, granska frågeplanen, lägga till saknade index och justera frågan effektivisera (endast nödvändiga kolumner, paginering med LIMIT/OFFSET eller med hjälp av markörer). Samtidigt ställer jag in tillfälligt strängare inställningar för den här användaren korta intervall, så att toppen omedelbart dämpas, och lätta på dessa åtgärder så snart korrigeringen har trätt i kraft och kurvan sjunker stadigt.
Samverkan med LVE: tvåstegskontroll
Jag betraktar MySQL Governor som första Databasskyddslagret och LVE fungerar som en andra broms om belastningen varar längre. Governor begränsar databasaktiviteten på ett målinriktat sätt, medan LVE dessutom strikt reglerar kontots totala CPU-, RAM- och IO-användning. Denna kombination förhindrar att ett konto går utom kontroll genom att enbart upprepa korta sökfrågor. Om aktiviteten förblir hög, träder LVE och sänker kontots processprioritet, vilket avlastar databasen märkbart. På så sätt förblir servicekvaliteten tillförlitlig för alla kunder, även under belastningsvågor och trafiktoppar.
Gränsvärden i praktiken: Exempelvärden
När det gäller vanliga delade servrar börjar jag med CPU-Gränser mellan 80–150% per konto under korta tidsintervall och minskar dem avsevärt under långa tidsintervall. När det gäller READ/WRITE börjar jag ofta med 4–12 MB/s på kort sikt och skruvar ner det på lång sikt, så att hårddisken inte hamnar i permanenta väntetider. Antalet samtidiga anslutningar begränsar jag gärna till 30, eftersom överdrivna anslutningar snabbt tömmer trådpoolerna. Sådana startvärden fungerar som utgångspunkt, men jag justerar dem utifrån faktiska data från dbtop och lveinfo. Det viktiga är att jag tillåter kortvariga toppar, men konsekvent förhindrar att resurserna utnyttjas till det yttersta under en längre tid.
Undantag, vitlistor och underhållsfönster
Vissa konton behöver ibland lite andrum: stora Import, migrering av webbutiker, omindexering. Jag planerar sådana åtgärder under tidsfönster utanför de tidpunkter då användningen är som störst och sätter i förväg tillfälligt högre gränser per användare. När åtgärderna är avslutade återställer jag standardvärdena med hjälp av ett skript. Det är också lämpligt med en liten Whitelist för systemkritiska konton som aldrig ska begränsas (t.ex. interna serviceanvändare). Jag dokumenterar varje undantag med start- och sluttid samt målvärden, så att avvikelsen kan förklaras vid senare analyser. På så sätt förblir styrningen spårbar utan att legitimt underhållsarbete hindras.
WordPress och plugins: hantera vanliga orsaker till problem
I CMS-installationer ser jag ofta dyra JOINs, dynamiska widgetar utan cache och cron-jobb som varje timme skannar hela tabeller. Governor skyddar pålitligt här, men jag åtgärdar dessutom orsaken i själva applikationen. Jag aktiverar objektcache, minskar antalet sökfrågor och använder där det är lämpligt Poolning av anslutningar, för att undvika Connect/Disconnect-stormar. I kombination med tydliga CPU/IO-begränsningar minskar jag svarstiderna märkbart och håller Last kontrollerbar. Denna kombination minskar antalet supportärenden och jämnar ut toppar innan de belastar servern.
Schema- och indexunderhåll i praktiken
Jag kontrollerar regelbundet om tabeller och index fortfarande är relevanta för Åtkomstmönster passar. Nya funktioner och plugins förändrar ofta sökfrågorna på ett subtilt sätt: ett extra filter, ett annat sorteringskriterium – och plötsligt fungerar inte det gamla indexet längre. Jag prioriterar därför index för vanliga WHERE-kolumner och minskar överlappande index och ersätt sökningar med LIKE-prefix med mer precisa fält. För arkivtabeller använder jag partitionskoncept eller tidsstämpelfilter för att undvika fullständiga genomsökningar. Governor hanterar konsekvenserna av dåliga scheman, men det mest effektiva är att data lättillgänglig att strukturera.
Anslutningshantering: Undvika 500-fel
Alltför många samtidiga anslutningar leder ofta till att tjänsterna bryts Time-outs, som visar sig som 500-fel. Jag kontrollerar först anslutningshastigheten per användare och utnyttjandet av trådpoolen. Om det finns tecken på anslutningsstormar skärper jag gränserna och inför caching på fråge- eller objektnivå. Som komplement förklarar inlägget om 500-fel på grund av anslutningar Vanliga orsaker till och åtgärder mot detta flaskhalsproblem. Sammanfattningsvis säkerställer jag MySQL-stacken och håller Fördröjning förutsägbar.
Att hitta rätt balans mellan pooling och keep-alive
Jag dimensionerar pooler liten, men konstant: tillräckligt för att täcka typisk parallellitet utan att blockera servern med inaktiva sessioner. Långa keep-alive-tider jämnar ut belastningstoppar, men får inte leda till att många vilande anslutningar binder upp resurser. Därför mäter jag uppehållstid och inaktivitet per konto och justerar poolstorlekar samt sessionstimeouts därefter. Tillsammans med guvernören förhindrar jag på så sätt att okontrollerad upp- och nedkoppling av anslutningar slukar CPU-resurser, samtidigt som överdimensionerade pooler onödigt belastar trådpoolen.
Att tolka övervakningsnyckeltal på rätt sätt
Jag gör en tydlig åtskillnad mellan CPU och I/O, eftersom dessa två resurser begränsar prestandan på helt olika sätt. Om CPU-användningen ökar kraftigt utan motsvarande I/O-värden, är det ofta logiken, parsningen eller en ineffektiv plan som orsakar blockeringar; vid hög I/O-användning och låg CPU-användning tyder fullskanningar eller saknade index på flaskhalsen. Jag utvärderar alltid READ/WRITE utan cache för att kunna identifiera den verkliga diskbelastningen och inte bara minnesåtkomst. Dessutom tittar jag på anslutningstid, aktiva trådar och frågelängd för att tidigt upptäcka långsamma processer. Utifrån dessa mönster avgör jag vilken gräns jag ska sätta och vilket intervall jag ska strama åt.
Beakta faktorer som rör hårdvara och motor
Die Lagringsklass bestämmer vilka gränsvärden som är praktiskt genomförbara. På NVMe kan jag tillåta högre läs- och skrivvärden på kort sikt, medan jag på HDD planerar mer konservativt och håller striktare gränser för långa intervall. Jag observerar dessutom hur motorn buffrar: Aggressiva bakgrundsskrivare kan jämna ut toppar, men också skapa till synes „lugna“ faser där skrivningar drar ut på tiden. Därför korrelerar jag guvernörsmetriker med fysisk I/O och väntetider på blockenheten. Målet är alltid en mer stabil Medianvärden istället för maximala genomströmningsvärden på bekostnad av latensen.
Jämförelse mellan ”Monitor-only” och ”Abusen”
Jag använder Monitor-only-läge för att samla in verkliga användningsprofiler och fastställa basvärden. Så snart jag har fastställt rimliga gränsvärden växlar jag till Abusen-läge, så att regulatorn automatiskt begränsar konton vid överbelastning. Det första läget minskar antalet falska larm, det andra förhindrar oönskade effekter under verkliga toppar. Beroende på erfarenhetsnivå kan jag arbeta med strängare inställningar under långa intervall och ge lite mer utrymme under korta intervall. Denna sekvens säkerställer att gränsvärdena inte fastställs på en känsla, utan utifrån en Mätning följa.
Lanseringsplan och kommunikation
Jag startar aldrig Governor med „Big Bang“. Metoden är beprövad: 1) Inventarieförteckning de aktiva kontona, grov gruppering efter belastningsprofiler. 2) Endast skärm i minst en till två veckor för att kartlägga veckomönster. 3) Fastställande av basgränser per kluster och kontrollerad lansering i omgångar, varvid KPI:erna (felprocent, P95-latens, avbrottsfrekvens) noggrant övervakas. 4) Finjustering och dokumentation av undantag. Samtidigt informerar jag kunderna proaktivt om målet „Fair Share“, typiska orsaker till begränsningar och lämpliga optimeringar. Öppenhet minskar antalet frågor och ökar acceptansen för begränsningarna.
Säkerhetskopiering, backup och säkerhetskopiering av specialanvändare
Användare som arbetar nära systemet, såsom Replikering- eller . Backup-användare får inte bromsas oväntat. Jag klassificerar sådana konton tydligt, dokumenterar dem och undantar dem från automatiska begränsningar. För säkerhetskopieringar planerar jag läsgränser som ligger under lagringens komfortzon, så att användarbelastningen inte påverkas samtidigt. Vid replikering ser jag till att upphämtningsprocesser inte äventyrar produktionsbelastningen: korta intervall hanteras något mer generöst, långa intervall mer konservativt, så att långvarig upphämtning inte blir en ständig broms. Det är viktigt att ha en tydlig åtskillnad mellan Service- och kundkonton, så att nyckeltalen förblir entydiga.
Nödåtgärder vid akut överbelastning
Om det trots gränserna uppstår en märkbar försämring, arbetar jag in Spelguide Åtgärder: 1) Identifiera det användarkonto som ligger i topp i dbtop och skärpa dess gränsvärden tillfälligt. 2) Minska anslutningsgränsen för denna användare för att avlasta trådpoolen. 3) Synliggör långvariga processer och optimera eller pausa misstänkta frågor i prioriterad ordning. 4) Vid hög systembelastning, sänk tillfälligt LVE-gränserna för den skyldige för att stabilisera plattformen. 5) När situationen har lugnat sig, återställ gradvis inställningarna och åtgärda orsaken permanent (index, cache, kod). Jag dokumenterar varje åtgärd med tidpunkt och uppmätt effekt, så att framtida insatser kan genomföras snabbare.
I korthet: praktiskt tillämpbara riktlinjer
Jag satsar på tydligt åtskilda Gränser för CPU, READ och WRITE, eftersom varje resurs påverkar på olika sätt. Jag börjar försiktigt, mäter effekterna i ”Monitor-only”-läget och sätter gränser i ”Abusen”-läget så snart kurvorna tydligt visar i vilken riktning utvecklingen går. Jag håller striktare gränser för långsiktiga intervall och håller mig under de globala LVE-gränserna så att den andra skyddsnivån säkert träder i kraft vid behov. Jag håller koll på antalet anslutningar, börjar med 30 sessioner per konto och justerar beroende på arbetsbelastning och tid på dygnet. Jag kombinerar teknisk styrning med att åtgärda orsakerna i applikationen, eftersom jag på så sätt håller Databas pålitligt, rättvist och smidigt för alla projekt på samma server.
