Sådan forstår og kontrollerer du CloudLinux LVE-grænser i delt hosting

Hvad der begrænser en LVE ved shared hosting

Ved shared hosting deler flere kunder ressourcerne på en server. CloudLinux kan overvåge brugen af en kundekonto med en Letvægtsvirtualiseret miljø, kort sagt LVE. Udbyderen fastsætter, hvilke grænser der gælder. De skal forhindre, at en konto bruger ubegrænsede ressourcer; omvendt kan ens egen hjemmeside også støde på disse grænser.

En grænse angiver et loft og er ikke nødvendigvis en reserveret ydelse. En CPU-grænse betyder for eksempel ikke, at du har eksklusiv adgang til en processorkerne, eller at du er garanteret en bestemt responstid. Hvor hurtigt et program kører, afhænger også af dets opgave, hardwaren og andre komponenter.

Et LVE gør heller ikke din hostingpakke til en egen server. Udbyderen driver fortsat det fælles miljø og bestemmer dets konfiguration. Som kunde kan du kun selv kontrollere de gældende indstillinger og deres konsekvenser i det omfang, din pakke og hostingpanelet stiller de relevante oplysninger til rådighed.

Dette skal adskilles fra CageFS: Det drejer sig om isolering af filsystemet, mens LVE-grænser begrænser ressourceforbruget. De to funktioner kan supplere hinanden, men er ikke det samme. Udbyderen kan bekræfte, hvilke komponenter der rent faktisk er aktive i dit abonnement.

Du kan finde en mere detaljeret beskrivelse af komponenterne i artiklen om Procesisolering med CloudLinux SecureLVE. Når det kommer til den konkrete fejlfinding, er det dog afgørende, hvordan din egen pakke er konfigureret: Brugergrænsefladen og detaljeringsgraden i ressourcevisningen kan variere afhængigt af panelet og aktiveringen.

Hvem gælder grænserne for?

Det afgørende er ikke kun størrelsen på en grænse, men også dens Anvendelsesområde. Hvis du for eksempel driver en blog og en webshop under samme hostingkonto, kan begge dele trække på det samme ressourcebudget i en kontobaseret konfiguration. En import i webshoppen kan så optage kapacitet, som bloggen også har brug for på samme tid.

Det betyder ikke, at hver eneste langsom side skyldes et andet projekt på kontoen. Det forklarer dog, hvorfor du i en kritisk situation ikke kun bør se på det domæne, der netop er berørt. Også planlagte opgaver og andre hjemmesider på samme konto kan være relevante i den pågældende periode.

CloudLinux dokumenterer med Isolater Derudover er der mulighed for at indstille begrænsninger på webstedsniveau. Om denne funktion anvendes, og hvordan tildelingen ser ud i det pågældende tilbud, kan ikke udledes alene ud fra betegnelsen CloudLinux. En separat vurdering kan derfor heller ikke erstatte en gennemgang af de konkrete abonnementsbetingelser.

Spørg udbyderen så konkret som muligt, inden du sammenligner priser: Gælder SPEED, PMEM, IO, IOPS, EP og NPROC pr. hostingkonto eller pr. hjemmeside? Hvis flere projekter deler et budget, er det desuden vigtigt at vide, hvilke domæner og opgaver der er tilknyttet dette budget. På den måde undgår du ved en fejltagelse at medregne en angivet værdi for hver enkelt hjemmeside.

Hvis panelet kun viser en samlet statistik, hjælper denne i første omgang med at afgrænse tidsrammen, men ikke nødvendigvis med at tilknytte belastningen til en bestemt applikation. Kontakt venligst supporten for at få oplyst, hvilke opdelinger der er tilgængelige, og om belastningen kan tilknyttes et projekt eller en opgave.

Skelne mellem CPU, hukommelse og adgangsbegrænsninger

De forskellige begrænsninger for delt hosting sætter grænser for forskellige typer aktiviteter. SPEED står for CPU-budgettet: Hvis det udnyttes fuldt ud, bliver beregningskrævende processer bremset, og forespørgsler kan tage længere tid. En CPU-begrænsning i hosting er derfor kun en mulig forklaring på langsomme sider og er ikke det samme som alle LVE-grænser.

PMEM begrænser LVE’s fysiske hukommelse. Ved hukommelsespres kan cachen først frigives; hvis det ikke er nok, kan processer afsluttes. Den forældede værdi VMEM for virtuel hukommelse skal skelnes herfra. Det samme gælder PHP-memory_limit kan ikke sidestilles med hele LVE’s PMEM-budget.

Når det gælder filadgang, måler IO og IOPS forskellige ting: IO vedrører datagennemstrømningen, mens IOPS angiver antallet af læse- og skriveoperationer pr. sekund. Mange små filer kan derfor udgøre en anden belastning end få store filer. IO henviser her ikke til hastigheden på din internetforbindelse.

EP tæller antallet af indgange til LVE og udgør ikke en generel grænse for antallet af samtidige besøgende. Hvordan indgangene tælles, afhænger blandt andet af webserveren og procesmodellen. NPROC begrænser derimod antallet af processer og tråde. Når denne grænse er nået, kan der midlertidigt ikke oprettes flere processer; EP og NPROC er derfor ikke indbyrdes udskiftelige.

Lagringsplads og inoder er relaterede, men separate oplysninger i abonnementet. En opbrugt filkvote eller en overskredet inodegrense er ikke automatisk et problem med CPU, PMEM eller EP. Hvilke af disse værdier du selv kan se i kontrolpanelet, afhænger af udbyderen og den tilgængelige brugergrænseflade.

Oversigt over LVE-grænser og deres konsekvenser

LVE-grænserne virker ikke alle på samme måde: Nogle bremser igangværende arbejde, andre forhindrer nye processer eller kan afbryde eksisterende processer. Tabellen hjælper dig med at knytte en vist ressource til dens adfærd og et passende kontrolspor. De konkrete grænseværdier fastsættes af din udbyder.

På PMEM-grænse Det er ikke kun hukommelsen i de enkelte applikationsprocesser, der tæller med. Også delt hukommelse og filcache kan indgå i beregningen; om cachen medregnes, afhænger af konfigurationen. Når processer afsluttes, kan der opstå HTTP-fejl, men det er ikke nødvendigvis den synlige konsekvens.

De to grænser for filadgang beskriver forskellige størrelser: IO begrænser datagennemstrømningen, mens IOPS angiver antallet af operationer. Mange små filer kan derfor især belaste IOPS, mens store filer kan skabe en høj gennemstrømning. IO står her ikke for netværksbåndbredden; ifølge CloudLinux tæller adgang fra filcachen ikke med i IO-grænsen.

Beregning af CPU-grænse ved hjælp af et eksempel

Lad os antage, at din pakke havde en Hastighedsgrænse på 150 procent. Da 100 procent matematisk svarer til en processorkerne, giver det et CPU-budget svarende til halvanden kerne. Dette er et illustrativt regneeksempel, ikke en måling. Den faktiske værdi af din pakke kan være anderledes; det er udbyderens angivelse, der er afgørende.

Eksemplet beskriver en øvre grænse for den anvendelige CPU-tid, ikke en reservation af en eksklusiv kerne. Det betyder heller ikke, at hver enkelt proces kan bruge halvanden kerne på samme tid. Hvordan budgettet fordeles på de kørende opgaver, afhænger blandt andet af, hvor mange processer der faktisk har brug for regnetid parallelt.

150 procent betyder hverken en garanteret svartid eller et bestemt antal besøgende, der kan betjenes samtidigt. Et simpelt opkald kan kræve meget lidt regnekraft, mens et dynamisk opkald derimod kan kræve betydeligt mere. Derudover kommer eventuelle ventetider i forbindelse med filadgang eller databasearbejde, som et højere CPU-budget ikke automatisk eliminerer.

Selv ens procentværdier på forskellige servere udgør ikke en direkte hastighedssammenligning: Processorkerner kan variere i ydeevne. For at vurdere din CPU-grænse er det derfor vigtigere, om udnyttelsen gentagne gange ligger på grænsen under et konkret problem, og om der er synlige grænsehændelser. Selv i så fald bør du undersøge andre mulige årsager.

Sådan aflæser man ressourceoversigten korrekt

Hvis din udbyder har aktiveret en ressourceoversigt, skal du starte med en hændelse, der er afgrænset så præcist som muligt. Notér domæne, dato, klokkeslæt og tidszone samt eventuelt den viste HTTP-status. Beskriv også, hvad der var langsomt eller mislykkedes. Uden disse oplysninger er det svært at knytte en spids i statistikken til et konkret problem.

Vælg derefter samme tidsperiode i visningen, og sammenlign for CPU, PMEM, IO, IOPS, EP og NPROC henholdsvis forbrug, indstillet grænse og eventuelt viste Fejl. Ikke alle grænseflader viser alle værdier på samme måde. Hvis der mangler statistikker, eller hvis det er uklart, hvilken konto de vedrører, skal du spørge udbyderen.

Vær opmærksom på Tidsopløsning: Et lavt timegennemsnit kan skjule en kortvarig spids, hvor en grænse er blevet nået. Vælg, hvis det er muligt, et kortere tidsrum eller en mere detaljeret visning. Sammenlign spidsen med den noterede fejltid, i stedet for udelukkende at konkludere ud fra et dags- eller timegennemsnit, at der ikke var tale om en flaskehals.

Fejl markerer grænsehændelser, men er ikke en direkte optælling af berørte besøgende eller mislykkede sidevisninger. En fejl, der opstår på det rette tidspunkt, er en indikation, men ikke et fuldstændigt bevis på årsagen. Kontroller derfor også, om der på samme tid fandt en import, en sikkerhedskopiering, en planlagt opgave eller en ændring af applikationen sted.

Brugergrænsefladen og dens funktioner afhænger af panelet og aktiveringen; der findes derfor ikke en universel menusti. For den tekniske baggrund for administrationen henvises til artiklen om CloudLinux LVE Manager og til ressourceadministration Yderligere oplysninger. De administrative konfigurationsskridt, der beskrives der, kræver dog de relevante rettigheder og er ikke automatisk tilgængelige for din kundekonto.

Klassificering af langsomme sider og fejl

Hvis dit CMS er langsomt, når du redigerer eller åbner sider dynamisk, skal du først sammenligne det pågældende tidsrum med CPU-visningen. Hvis forbruget gentagne gange ligger tæt på SPEED-grænsen, og der samtidig vises relevante fejl, er der tale om en CPU-begrænsning plausibelt. Den tidsmæssige sammenfald gør det til et spor, men beviser endnu ikke, hvilken opgave der har forårsaget belastningen.

Tjek for eksempel, om der kører planlagte opgaver på samme tid, eller om en ændring i udvidelser falder sammen med problemet. Også databasearbejde, netværksproblemer eller en ekstern grænseflade, der reagerer langsomt, kan forsinke siderne. En høj CPU-udnyttelse betyder derfor i sig selv hverken, at den valgte prisplan er forkert, eller at et bestemt plugin nødvendigvis er skyld i problemet.

Hvis der opstår fejl, når flere dynamiske forespørgsler ankommer samtidigt, kan en samtidig EP-fejl hjælpe. Langvarige forespørgsler holder indgange optaget i længere tid; samtidig kan en besøgende udløse flere forespørgsler. EP er derfor ikke en tælling af besøgende. I Apache er HTTP 508 en mulig konsekvens af, at EP-grænsen er overskredet, men statuskoden alene beviser ikke årsagen.

Hvis der vises en PMEM-fejl under en import, kan LVE-hukommelsesgrænsen være årsagen. Ud over importen kan samtidig kørende PHP-processer også optage hukommelse; uden relevante procesdata forbliver det uklart, hvilken opgave der var den afgørende faktor. Også en HTTP-500- eller 503-fejl kan have andre årsager og er i sig selv ikke et bevis på hukommelsesmangel.

PHP-værdien memory_limit Dette besvarer ikke spørgsmålet i sig selv: Det giver ikke et fuldstændigt billede af den samlede hukommelsesudnyttelse for alle opgaver i LVE. Sammenlign derfor importtidspunktet med PMEM-udnyttelsen og fejlene, og noter, hvilke andre opgaver der kørte parallelt, inden du ændrer en indstilling eller taksten.

Kontroller baggrundsbelastningen og inddrag supporten

Hvis en sikkerhedskopiering eller filimport går langsomt, skal du overveje IO og IOPS adskilt. IO angiver datagennemstrømningen ved harddiskadgang, mens IOPS angiver antallet af læse- og skriveoperationer pr. sekund. Mange små filer kan derfor udgøre en anden belastning end overførslen af få store filer; IO er i denne sammenhæng ikke det samme som internetbåndbredden.

En sikkerhedskopiering kan kræve både CPU- og hukommelsesressourcer på samme tid. Kontroller derfor ud over IO og IOPS også SPEED og PMEM for samme tidsperiode, i stedet for udelukkende at udlede årsagen ud fra varigheden. Hvis adgang sker via filcachen, tæller den ifølge CloudLinux ikke med i IO-grænsen; den viste IO-udnyttelse beskriver altså ikke alle filadgange på samme måde.

Hvis en planlagt opgave kan udskydes, skal du sammenligne dens normale forløb i en periode med mindre belastning med en tilsvarende tidligere periode. Tag i den forbindelse højde for omfanget og opgaver, der kører sideløbende: En mindre import kan ikke direkte sammenlignes med en fuldstændig sikkerhedskopiering. Yderligere belastningstests eller sletning af filer er ikke nødvendige for denne vurdering.

Den Indlæsning af database kan spille en rolle, selvom den viste web-CPU-udnyttelse er lav. Din tildeling til kontoen og eventuelle separate MySQL-begrænsninger afhænger af konfigurationen. Spørg udbyderen, hvilke databaseværdier du kan se i kontrolpanelet, og om databaseaktivitet medregnes i LVE eller begrænses separat.

Ved en supportforespørgsel er det nyttigt at angive domænet, tidspunktet med tidszone, den observerede HTTP-status og den berørte proces. Tilføj de grænseværdier, brugsværdier og fejl, der var synlige i samme tidsperiode, samt kendte import- eller backup-processer. Anmod venligst om en kortlægning af grænsehændelserne og, hvis det er muligt, en analyse af proces-snapshots; på den måde kan formodningen undersøges mere målrettet.

Optimere, opgradere eller skifte server?

Start med at Optimering en identificeret opgave, hvis ressourcebehovet kan reduceres på en gennemsigtig måde. Tjek f.eks. cache-indstillinger, udvidelser og parallelt planlagte baggrundsopgaver. Sammenlign derefter lignende tidsperioder, og vær opmærksom på både brugerproblemerne og de berørte ressourceværdier. En enkelt ændring gør det lettere at se, hvad der rent faktisk har ændret sig.

En opgradering er en mulighed, hvis tilbagevendende, belagte spidsbelastninger når de tildelte grænser på trods af passende optimering. Spørg på forhånd om de konkrete værdier for SPEED, PMEM, IO, IOPS, EP og NPROC. Sammenlign ikke kun pakkenavne: En højere CPU-grænse fjerner hverken en uafhængigt eksisterende EP-grænse eller en mangel på LVE-hukommelse.

Til den Sammenligning af takster Dette omfatter også anvendelsesområdet. Fortæl udbyderen, hvor mange hjemmesider din konto indeholder, og spørg, om de deler et fælles ressourcebudget, eller om der gælder begrænsninger pr. hjemmeside. CloudLinux tilbyder med »Isolates« en mulighed for det sidstnævnte; det fremgår dog ikke af produktnavnet alene, at din løsning anvender denne funktion.

En VPS eller en managed server kan give større fleksibilitet, men er ikke nødvendigvis den rette løsning for alle langsomme hjemmesider. Det afgørende er de tilgængelige ressourcer, den faktiske belastning og driftsmodellen: Ved en VPS skal du især afklare, hvilke administrative opgaver du selv skal varetage; ved en managed server skal du afklare, hvilke opgaver udbyderen varetager.

Hvis årsagen forbliver uafklaret, er det mere fornuftigt at indhente yderligere oplysninger om de registrerede tidspunkter og fejl end at skifte udstyr på baggrund af en formodning. Selv under en LVE-grænse kan applikationen, netværket eller databasen forårsage forsinkelser. Få bekræftet, hvilke statistikker og hvilken support der er tilgængelige i det pågældende tilbud, inden du træffer en beslutning.