Videre til indhold 
CloudLinux MySQL Governor begrænser databasebelastningen pr. konto og fordeler den retfærdigt, så enkelte forespørgsler ikke bremser hele hosting-tjenesten. Jeg bruger MySQL Governor, for at overvåge CPU, READ og WRITE pr. bruger i realtid og automatisk begrænse forbruget, hvis grænserne overskrides.
Centrale punkter
- Pro-konto i stedet for globale grænser
- CPU/LÆSNING/SKRIVNING styre separat
- Tilstande »Monitor-only« og misbrug li>LVE som det andet beskyttelsesniveau
- CLI-værktøjer til kontrol
Hvorfor enkelte forespørgsler bremser det hele op
I shared hosting-miljøer genererer der som regel kun få Forespørgsler den største belastning, ikke databasernes størrelse. Jeg ser ofte, at en fejlbehæftet forespørgsel eller et plugin med høj I/O pludselig monopoliserer CPU-tiden, og at ventetiden for andre brugere stiger mærkbart. Det er netop her, at guvernør fordi den gør belastningen pr. bruger synlig og ikke kun ser på det samlede gennemsnit. På den måde forhindrer jeg, at en „støjende nabo“ sætter alle andre projekter i stå, selvom deres arbejdsbelastning er på et sundt niveau. Med klare grænseværdier og en retfærdig fordeling sikrer jeg, at svartiderne er forudsigelige, og fjerner grundlaget for overdreven adgang.
Sådan fungerer MySQL Governor i praksis
Jeg starter ofte i Skærm-only-tilstand for at måle den faktiske brug uden at gribe ind. Derefter aktiverer jeg Abusen-tilstanden, som automatisk flytter konti med overdreven aktivitet til et begrænset miljø og dermed straks dæmper virkningen. Målingen er baseret på Tråd-Statistikker pr. MySQL/MariaDB-forbindelse, hvilket gør det muligt at få et overblik over CPU-, læse- og skriveandele pr. bruger. Ved vedvarende overbelastning træder den tildelte LVE desuden i kraft, hvilket yderligere bremser processer på disse konti. Denne to-trins procedure forhindrer eskaleringer, afbøder spidsbelastninger og beskytter uberørte projekter pålideligt.
Vælg grænseværdier og tidsvinduer med omtanke
Jeg sætter grænser på tværs af flere Intervaller, så jeg kan tolerere kortvarige spidsbelastninger, men pålideligt standse vedvarende overbelastning. Korte tidsvinduer må ligge højere, mellemstore skal være moderate, lange skal klart være strengere, og de bør holde sig under de overordnede LVE-grænser. CPU måler jeg som en procentdel pr. Kerne; ved otte kerner svarer 100% til en fuld kerne, hvilket sikrer, at fordelingen og retfærdigheden forbliver gennemsigtig. Jeg vurderer READ og WRITE ud fra reelle disk-I/O-værdier, altså uden cache-hits, så jeg kan se den faktiske belastning på lagringsmediet. For at opnå en velfungerende samlet konfiguration følger jeg de velafprøvede LVE-regler og detaljer som beskrevet i Korrekt konfiguration af LVE-grænser beskrevet.
Planlæg intervaller efter tidspunkt på dagen og profiler
Jeg vil gerne deponere profiler, der afhænger af tidspunktet på dagen: I spidsbelastningsperioden indstiller jeg de korte intervaller lidt mere generøst for at kunne håndtere legitime trafikspidser (f.eks. flash-udsalg i webshoppen). Om aftenen og om natten foretrækker jeg især at lange intervaller strammere, så langvarige opgaver ikke ubemærket udnytter harddisken fuldt ud. Til batch-vinduer definerer jeg egne profiler med lidt mere WRITE, men begrænset CPU, så importprocesser kører hurtigt, men ikke monopoliserer ressourcerne. Det er vigtigt at huske: Jeg ændrer aldrig alle indstillinger på én gang. Først justerer jeg CPU-brugen, observerer, og derefter READ/WRITE. Hver ændring får en klar observationsperiode, så årsag og virkning kan adskilles tydeligt.
CLI-værktøjer og hurtig fejlfinding
Jeg analyserer mistænkelige konti ved hjælp af dbtop i realtid, opdaterer jeg grænserne med dbctl og ser historiske data via lveinfo –dbgov. Disse værktøjer giver mig på få sekunder de relevante oplysninger om spidsbelastninger, langvarige forespørgsler og antallet af forbindelser pr. bruger. På den måde kan jeg se, om især CPU eller I/O-begrænsninger, om forbindelserne løber løbsk, eller om enkelte tabeller skaber flaskehalse i forespørgslerne. Ud fra mønstrene udleder jeg tilpassede tærskelværdier for hvert interval og tester ændringerne først i »Monitor-only«-tilstand. Først når kurverne falder på en plausibel måde, aktiverer jeg begrænsningen permanent.
| Værktøj | Formål | Eksempel |
|---|---|---|
| dbtop | Live-visning pr. bruger/tråd | dbtop – efter bruger |
| dbctl | Fastlægge grænser og styre tilstande | dbctl set userX cpu=120 read=8 write=6 |
| lveinfo –dbgov | Kontroller historik og overtrædelser | lveinfo –dbgov –id userX –period 1h |
Fejlfinding: typiske mønstre og hurtige afhjælpende foranstaltninger
Når CPU Når jeg kigger nærmere på en konto, finder jeg ofte mønstre som SELECT *, manglende WHERE-klausuler, komplekse ORDER BY-sætninger med store resultatsæt eller N+1-forespørgsler fra ORM’er. Hvad angår I/O, ser jeg fuldscanninger uden passende indekser, gentagne LIKE ‚%…%‘ eller JOIN'er på ikke-indekserede kolonner. Min fremgangsmåde: identificere de berørte tabeller, kontrollere forespørgselsplanen, tilføje manglende indekser og optimere forespørgslen strømline (kun de nødvendige kolonner, paginering med LIMIT/OFFSET eller cursor-metoder). Samtidig indstiller jeg midlertidigt strengere indstillinger for denne bruger korte intervaller, så toppen straks udjævnes, og lemp dem igen, så snart løsningen er i drift, og kurven falder stabilt.
Samspil med LVE: to-trins kontrol
Jeg betragter MySQL Governor som først Databasebeskyttelseslag og LVE fungerer som en ekstra sikkerhedsforanstaltning, hvis belastningen varer ved. Governor begrænser målrettet databaseaktiviteten, mens LVE derudover nøje styrer kontoens samlede CPU-, RAM- og IO-forbrug. Denne kombination forhindrer, at en konto kommer ud af kontrol ved blot at gentage korte forespørgsler. Hvis aktiviteten forbliver høj, træder LVE og sænker kontos procesprioritet, hvilket aflaster databasen mærkbart. På den måde forbliver servicekvaliteten pålidelig for alle kunder, selv under belastningsspidser og trafikspidser.
Grænseværdier i praksis: Eksempelværdier
På typiske delte servere starter jeg med CPU-Jeg sætter grænserne mellem 80–150% pr. konto på kort sigt og reducerer dem markant på lang sigt. READ/WRITE starter jeg ofte på 4–12 MB/s på kort sigt og strammer op på lang sigt, så harddisken ikke ender i konstante ventetider. Antallet af samtidige forbindelser begrænser jeg gerne til 30, fordi for mange forbindelser hurtigt udtømmer trådpuljerne. Sådanne startværdier er et godt udgangspunkt, men jeg justerer dem ud fra reelle data fra dbtop og lveinfo. Det vigtige er, at jeg tillader kortvarige spidsbelastninger, men konsekvent forhindrer vedvarende overbelastning.
Undtagelser, hvidlister og vedligeholdelsesvinduer
Nogle konti har i perioder brug for mere luft: store Import, migrering af webshops, reindeksering. Jeg planlægger sådanne tiltag i tidsvinduer uden for spidsbelastningstiderne og indstiller på forhånd midlertidigt højere grænser pr. bruger. Når det er afsluttet, gendanner jeg standardværdierne ved hjælp af et script. Det er ligeledes en god idé at lave en lille Whitelist for systemrelevante konti, der aldrig bør begrænses (f.eks. interne servicebrugere). Jeg dokumenterer hver undtagelse med start- og sluttidspunkt samt målværdier, så senere analyser kan forklare afvigelsen. På den måde forbliver styringen gennemsigtig, uden at legitimt vedligeholdelsesarbejde hindres.
WordPress og plugins: Sådan afhjælper du typiske problemer
I CMS-opsætninger ser jeg ofte dyre JOIN'er, dynamiske widgets uden cache og cron-jobs, der hver time gennemsøger fulde tabeller. Governor sikrer her pålidelig beskyttelse, men jeg løser desuden årsagen i selve applikationen. Jeg aktiverer objektcache, reducerer antallet af søgeforespørgsler og bruger, hvor det giver mening Pooling af forbindelser, for at undgå »Connect/Disconnect«-storme. I kombination med klare CPU/IO-grænser reducerer jeg responstiderne mærkbart og holder Belastning kontrollerbart. Denne kombination reducerer antallet af supportanmodninger og udjævner spidsbelastninger, inden de belaster serveren.
Skema- og indeksvedligeholdelse i praksis
Jeg kontrollerer regelmæssigt, om tabeller og indekser stadig er relevante for Adgangsmønster passer. Nye funktioner og plugins ændrer ofte forespørgslerne på en subtil måde: et ekstra filter, et andet sorteringskriterium – og så fungerer den gamle indeks ikke længere. Derfor prioriterer jeg indekser for hyppigt anvendte WHERE-kolonner og reducerer overlappende indekser og erstatter søgninger med LIKE-præfikser med mere præcise felter. Til arkivtabeller bruger jeg partitionskoncepter eller tidsstempelfiltre for at undgå fuldstændige scanninger. Governor afbøder konsekvenserne af dårlige skemaer, men det mest effektive er at brugervenlig at strukturere.
Forbindelsesstyring: Sådan undgår du 500-fejl
For mange samtidige forbindelser får ofte tjenesterne til at gå ned Time-outs, som vises som 500-fejl. Jeg tjekker først forbindelseshastigheden pr. bruger og udnyttelsen af trådpuljen. Hvis der er tegn på forbindelsesstorm, strammer jeg begrænsningerne og indfører caching på forespørgsels- eller objektniveau. Som supplement forklarer indlægget om 500-fejl på grund af forbindelser Typiske årsager til og foranstaltninger mod denne flaskehals. Samlet set sikrer jeg MySQL-stakken og holder Forsinkelse Forudsigelig.
Find den rette balance mellem pooling og keep-alive
Jeg beregner dimensionerne på svømmebassiner lille, men konstant: nok til at dække typisk parallelitet uden at blokere serveren med inaktive sessioner. Lange keep-alive-tider udjævner belastningsspidser, men må ikke føre til, at mange inaktive forbindelser binder ressourcer. Derfor måler jeg opholdstid og inaktivitet pr. konto og justerer poolstørrelser samt session-timeouts i overensstemmelse hermed. I kombination med Governor forhindrer jeg dermed, at voldsom oprettelse og nedlukning af forbindelser belaster CPU’en, samtidig med at overdimensionerede puljer unødigt optager plads i trådpuljen.
Sådan fortolker man nøgletal for overvågning korrekt
Jeg skelner klart mellem CPU og I/O, fordi disse to ressourcer udgør helt forskellige begrænsninger. Hvis CPU-belastningen stiger kraftigt uden tilsvarende I/O-værdier, er det ofte logikken, parsningen eller en ineffektiv plan, der blokerer; ved høj I/O og lav CPU-belastning er det fuldscanninger eller manglende indekser, der udgør flaskehalsen. Jeg vurderer altid READ/WRITE uden cache, så jeg kan identificere den reelle diskbelastning og ikke kun hukommelsesadgange. Desuden ser jeg på forbindelsens varighed, aktive tråde og forespørgslens længde for tidligt at opdage langsomme kørsler. Ud fra disse mønstre afgør jeg, hvilken grænse jeg sætter, og hvilket interval jeg strammer op.
Tage højde for hardware- og engine-faktorer
Die Lagringsklasse bestemmer, hvilke grænseværdier der er praktisk gennemførlige. På NVMe kan jeg på kort sigt tillade højere READ/WRITE-værdier, mens jeg på HDD planlægger mere konservativt og overholder de lange intervaller strengere. Jeg holder desuden øje med, hvordan motoren bufferer: Aggressive baggrundsskrivere kan udjævne spidsbelastninger, men kan også skabe tilsyneladende „rolige“ faser, hvor skrivningerne halter bagefter. Derfor sammenholder jeg governor-metrikker med fysisk I/O og ventetider på blokenheden. Målet er altid en mere stabil Median i stedet for maksimale gennemstrømningsværdier på bekostning af latenstiden.
Sammenligning af »Monitor-only« og »Abusen«
Jeg bruger Skærm-only-tilstand for at indsamle reelle brugsprofiler og udlede basislinjer. Så snart jeg har fastsat plausible grænseværdier, skifter jeg til »Abusen«, så regulatoren automatisk begrænser konti med overbelastning. Den første tilstand reducerer falske alarmer, den anden forhindrer følgeskader under reelle spidsbelastninger. Afhængigt af erfaringsniveauet kan jeg arbejde med strengere lange intervaller og give lidt mere spillerum i korte intervaller. Denne rækkefølge sikrer, at grænseværdier ikke fastsættes ud fra mavefornemmelse, men på baggrund af en Måling følge.
Implementeringsplan og kommunikation
Jeg sætter aldrig Governor-en i gang med „Big Bang“. Fremgangsmåden er gennemprøvet: 1) Inventar de aktive konti, grov gruppering efter belastningsprofiler. 2) Kun skærm i mindst en til to uger for at registrere ugemønstre. 3) Fastlæggelse af basisgrænser pr. klynge og kontrolleret udrulning i etaper, hver gang med nøje overvågning af KPI’erne (fejlprocent, P95-latens, afbrydelsesprocent). 4) Finjustering og dokumentation af undtagelser. Sideløbende informerer jeg proaktivt kunderne om målet „Fair Share“, typiske årsager til begrænsninger og fornuftige optimeringer. Gennemsigtighed mindsker antallet af forespørgsler og øger accepten af begrænsningerne.
Sikkerhedskopiering, backup og sikkerhedskopiering af særlige brugere
Brugere, der arbejder tæt sammen med systemet, såsom Replikations- eller Backup-bruger må ikke bremses uventet. Jeg tildeler sådanne konti tydeligt, dokumenterer dem og undtager dem fra automatiske begrænsninger. Til sikkerhedskopier planlægger jeg læsegrænser, der ligger under lagerkapacitetens komfortzone, så brugerbelastningen ikke påvirkes samtidig. Ved replikering sørger jeg for, at indhentningsprocesser ikke truer produktionsbelastningen: korte intervaller lidt mere generøse, lange intervaller konservative, så vedvarende indhentning ikke bliver en permanent bremse. Det er vigtigt at opretholde en klar adskillelse mellem Service- og kundekonti, så nøgletallene forbliver entydige.
Nødprocedurer ved akut overbelastning
Hvis der trods begrænsningerne opstår en mærkbar forringelse, indarbejder jeg en Playbook Gør følgende: 1) Identificer den største konto i dbtop og skærp dens grænser midlertidigt. 2) Reducer forbindelsesloftet for denne bruger for at aflaste trådpuljen. 3) Gør langvarige forespørgsler synlige, og optimer eller sæt iøjnefaldende forespørgsler på pause med høj prioritet. 4) Ved stor systembelastning sænkes den pågældende brugers LVE-grænser midlertidigt for at stabilisere platformen. 5) Når situationen er stabiliseret, skrues indstillingerne gradvist tilbage, og årsagen afhjælpes permanent (indeks, cache, kode). Jeg logger hver enkelt foranstaltning med tidspunkt og målt effekt, så fremtidige indsatser kan gennemføres hurtigere.
Kort sagt: praktisk anvendelige retningslinjer
Jeg lægger vægt på klart adskilte Grænser for CPU, READ og WRITE, fordi hver ressource virker forskelligt. Jeg starter forsigtigt, måler effekterne i »Monitor-only«-tilstand og sætter grænser i »Abusen«-tilstand, så snart kurverne tydeligt viser, i hvilken retning det går. Jeg holder de langsigtede intervaller strammere og holder mig under de globale LVE-grænser, så det andet beskyttelsesniveau træder sikkert i kraft, hvis det bliver nødvendigt. Jeg holder øje med antallet af forbindelser, starter med 30 sessioner pr. konto og justerer afhængigt af arbejdsbyrden og tidspunktet på dagen. Jeg kombinerer teknisk styring med årsagsarbejde i applikationen, for på den måde holder jeg Database pålidelig, retfærdig og hurtig til alle projekter på samme server.
