Att förstå och kontrollera CloudLinux LVE-gränser vid delad hosting

Vad som begränsar en LVE vid delad hosting

Vid delad hosting delar flera kunder på en servers resurser. CloudLinux kan övervaka användningen av ett kundkonto med hjälp av en Lättviktig virtualiserad miljö, förkortat LVE. Leverantören fastställer vilka gränser som gäller. Syftet är att förhindra att ett konto tar upp obegränsade resurser; omvänt kan även den egna webbplatsen stöta på dessa gränser.

En gräns anger ett övre värde och innebär inte automatiskt en garanterad prestanda. En CPU-gräns innebär till exempel inte att du har exklusiv tillgång till en processorkärna eller att en viss svarstid garanteras. Hur snabbt en applikation fungerar beror också på dess uppgift, hårdvaran och andra komponenter.

En LVE innebär inte heller att ditt webbhotellpaket blir en egen server. Leverantören fortsätter att driva den gemensamma miljön och bestämmer dess konfiguration. Som kund kan du själv kontrollera de gällande inställningarna och deras konsekvenser endast i den utsträckning som ditt abonnemang och webbhotellspanelen tillhandahåller sådan information.

Detta ska skiljas från CageFS: Det handlar om isolering av filsystemets synfält, medan LVE-gränser begränsar resursanvändningen. De båda funktionerna kan komplettera varandra, men är inte samma sak. Leverantören kan bekräfta vilka komponenter som faktiskt är aktiva i ditt abonnemang.

En mer ingående beskrivning av komponenterna hittar du i artikeln om Processisolering med CloudLinux SecureLVE. För den konkreta felsökningen är det dock konfigurationen av ditt eget paket som är avgörande: Gränssnittet och detaljnivån i resursvisningen kan variera beroende på panel och aktivering.

Vem omfattas av gränserna?

Det avgörande är inte bara gränsens storlek, utan också dess Tillämpningsområde. Om du till exempel driver en blogg och en webbutik på samma webbhotellskonto kan båda ta del av samma resursbudget i en kontobaserad konfiguration. En import i webbutiken kan då ta upp kapacitet som bloggen också behöver vid samma tidpunkt.

Det betyder inte att varje långsam sida orsakas av ett annat projekt i kontot. Det förklarar dock varför du vid en gränshändelse inte bara bör titta på den domän som just nu är drabbad. Även schemalagda uppgifter och andra webbplatser i samma konto kan vara relevanta under den aktuella tidsperioden.

CloudLinux dokumenteras med Isolat dessutom en möjlighet att sätta gränser på webbplatsnivå. Om denna funktion används och hur tilldelningen ser ut i det aktuella erbjudandet går inte att avgöra enbart utifrån benämningen CloudLinux. En separat granskning ersätter därför inte en genomgång av de konkreta avtalsvillkoren.

Ställ så konkreta frågor som möjligt till leverantören innan du jämför priser: Gäller SPEED, PMEM, IO, IOPS, EP och NPROC per webbhotellskonto eller per webbplats? Om flera projekt delar på en budget är det dessutom viktigt att veta vilka domäner och uppgifter som tillhör denna budget. På så sätt undviker du att av misstag räkna in ett angivet värde för varje enskild webbplats.

Om panelen endast visar en sammanställd statistik kan denna inledningsvis hjälpa till att avgränsa tidsperioden, men inte nödvändigtvis att koppla den till en enskild applikation. Kontakta då supporten för att få information om vilken uppdelning som finns tillgänglig och om belastningen kan kopplas till ett projekt eller en uppgift.

Skillnader mellan CPU, minne och åtkomstbegränsningar

De olika gränserna för delad hosting begränsar olika typer av verksamhet. SPEED avser CPU-budgeten: Om den utnyttjas fullt ut kommer beräkningskrävande processer att begränsas och förfrågningar kan ta längre tid. En CPU-begränsning i webbhotellet är därmed bara en möjlig förklaring till långsamma sidor och är inte detsamma som alla LVE-gränser.

PMEM begränsar LVE:s fysiska minne. Vid minnesbrist kan cacheminnet först frigöras; om det inte räcker kan processer avslutas. Detta ska inte förväxlas med det föråldrade värdet VMEM för virtuellt minne. På samma sätt gäller PHP-memory_limit inte ska likställas med LVE:s totala PMEM-budget.

När det gäller filåtkomst mäter IO och IOPS olika saker: IO avser datagenomströmningen, medan IOPS avser antalet läs- och skrivoperationer per sekund. Många små filer kan därför utgöra en annan belastning än ett fåtal stora filer. IO avser här inte hastigheten på din internetanslutning.

EP räknar antalet inloggningar i LVE och utgör inte någon allmän gräns för antalet samtidiga besökare. Hur inloggningarna räknas beror bland annat på webbservern och processmodellen. NPROC begränsar däremot antalet processer och trådar. När denna gräns nås kan inga ytterligare processer skapas tillfälligt; EP och NPROC är därför inte utbytbara.

Lagringsutrymme och inoder är relaterade, men separata uppgifter i abonnemanget. En full filkvot eller en uttömd inodgräns innebär inte automatiskt ett problem med CPU, PMEM eller EP. Vilka av dessa värden du själv ser i kontrollpanelen beror på leverantören och det gränssnitt som tillhandahålls.

Översikt över LVE-gränser och deras konsekvenser

LVE-gränserna fungerar inte alla på samma sätt: vissa bromsar pågående arbete, andra förhindrar nya processer eller kan avbryta befintliga processer. Tabellen hjälper dig att koppla ihop en visad resurs med dess beteende och en lämplig granskningsspår. De konkreta gränsvärdena fastställs av din leverantör.

På PMEM-gräns Det är inte bara minnet för enskilda applikationsprocesser som räknas. Även delat minne och filcache kan ingå; huruvida cache räknas med beror på konfigurationen. När processer avslutas kan HTTP-fel uppstå, men detta är inte nödvändigtvis den synliga följden.

De två gränserna för filåtkomst avser olika storheter: IO begränsar datagenomströmningen, medan IOPS anger antalet operationer. Många små filer kan därför framför allt belasta IOPS, medan stora filer kan generera hög genomströmning. IO står här inte för nätverksbandbredden; enligt CloudLinux räknas åtkomst från filcachen inte in i IO-gränsen.

Beräkna CPU-gränsen med hjälp av ett exempel

Låt oss anta att ditt paket hade ett Hastighetsbegränsning på 150 procent. Eftersom 100 procent matematiskt motsvarar en processorkärna, ger detta en CPU-budget som motsvarar en och en halv kärna. Detta är ett illustrativt räkneexempel, inte en mätning. Det faktiska värdet för ditt paket kan vara ett annat; leverantörens uppgifter är avgörande.

Exemplet beskriver en övre gräns för den tillgängliga CPU-tiden, inte en reservering av en exklusiv kärna. Det innebär inte heller att varje enskild process kan använda en och en halv kärna samtidigt. Hur budgeten fördelas på pågående arbete beror bland annat på hur många processer som faktiskt behöver beräkningstid parallellt.

150 procent innebär varken en garanterad svarstid eller ett visst antal besökare som kan betjänas samtidigt. En enkel förfrågan kan kräva lite beräkningsarbete, medan en dynamisk förfrågan däremot kan kräva betydligt mer. Till detta kommer eventuella väntetider vid filåtkomst eller databasbearbetning, vilket inte automatiskt elimineras av en högre CPU-budget.

Även om procentvärdena är desamma på olika servrar innebär det inte en direkt jämförelse av hastigheten: processorkärnornas prestanda kan variera. För att bedöma din CPU-gräns är det därför viktigare att se om utnyttjandet upprepade gånger ligger nära gränsen under ett specifikt problem och om motsvarande gränshändelser syns. Även i sådana fall bör du undersöka andra möjliga orsaker.

Att tolka resursindikatorn på rätt sätt

Om din leverantör har aktiverat en resursöversikt, börja med en så noggrant avgränsad händelse som möjligt. Notera domän, datum, klockslag och tidszon samt, om tillämpligt, den visade HTTP-statusen. Beskriv också vad som var långsamt eller misslyckades. Utan dessa uppgifter är det svårt att koppla en topp i statistiken till ett konkret problem.

Välj sedan samma tidsperiod i displayen och jämför för CPU, PMEM, IO, IOPS, EP och NPROC respektive användning, inställd gräns och eventuellt visade Fel. Alla gränssnitt visar inte alla värden på samma sätt. Om det saknas statistik eller om det är oklart vilket konto den avser, kontakta leverantören.

Var uppmärksam på Tidsupplösning: Ett lågt timgenomsnitt kan dölja en kort topp där en gräns har nåtts. Välj, om möjligt, en kortare tidsperiod eller en mer detaljerad visning. Jämför toppen med den noterade feltiden, istället för att enbart utifrån ett dags- eller timgenomsnitt dra slutsatsen att det inte förekom någon flaskhals.

Fel markerar gränsfall, men utgör inte en direkt räkning av berörda besökare eller misslyckade sidvisningar. Ett fel som inträffar vid rätt tidpunkt är en indikation, men ännu inte ett fullständigt bevis på orsaken. Kontrollera därför även om en import, en säkerhetskopiering, en schemalagd uppgift eller en ändring i applikationen ägde rum vid samma tidpunkt.

Gränssnittet och dess funktioner beror på vilken panel och vilken aktivering som används; det finns därför ingen universell menyväg. För den tekniska bakgrunden till administrationen finns artikeln om CloudLinux LVE Manager och för resurshantering Mer information. De administrativa konfigurationsstegen där kräver dock motsvarande behörigheter och är inte automatiskt tillgängliga för ditt kundkonto.

Klassificera långsamma sidor och fel

Om ditt CMS är långsamt vid redigering eller vid dynamiska sidvisningar, bör du först jämföra den berörda tidsperioden med CPU-indikatorn. Om användningen upprepade gånger ligger nära SPEED-gränsen och motsvarande fel visas, är det en CPU-begränsning Troligt. Att tidpunkten stämmer överens gör det till ett spår, men bevisar ännu inte vilken uppgift lasten orsakade.

Kontrollera till exempel om det finns schemalagda uppgifter som körs samtidigt eller om problemet sammanfaller med en ändring i tillägg. Även databasarbete, nätverksproblem eller ett externt gränssnitt som reagerar långsamt kan orsaka fördröjningar på sidorna. En hög CPU-belastning i sig innebär därför varken att man har valt fel abonnemang eller att ett visst tillägg nödvändigtvis är orsaken.

Om fel uppstår när flera dynamiska förfrågningar anländer samtidigt kan en samtidig EP-fel hjälpa till. Förfrågningar som pågår under lång tid håller anslutningarna upptagna under en längre tid; samtidigt kan en besökare generera flera förfrågningar. EP är därför ingen besöksräkning. I Apache är HTTP 508 en möjlig följd av att EP-gränsen överskrids, men statuskoden i sig bevisar inte orsaken.

Om skärmen visar PMEM-fel under en import kan LVE-minnesgränsen vara orsaken. Förutom importen kan även PHP-processer som körs samtidigt ta upp minne; utan lämpliga processdata är det oklart vilken uppgift som var avgörande. Även ett HTTP-500- eller 503-fel kan ha andra orsaker och är i sig inte ett bevis på minnesbrist.

PHP-värdet memory_limit Detta besvarar inte frågan i sig: Det ger ingen bild av den totala minnesanvändningen för alla uppgifter i LVE. Jämför därför importtidpunkten med PMEM-användningen och felen, och notera vilka andra uppgifter som kördes parallellt innan du ändrar en inställning eller tariffen.

Kontrollera bakgrundsbelastningen och kontakta supporten

Om en säkerhetskopiering eller filimport går långsamt, bör du överväga IO och IOPS skiljer sig åt. IO begränsar datagenomströmningen vid åtkomst till hårddiskar, medan IOPS anger antalet läs- och skrivoperationer per sekund. Många små filer kan därför utgöra en annan belastning än överföringen av ett fåtal större filer; IO är i detta sammanhang inte detsamma som internetbandbredd.

En säkerhetskopiering kan kräva både CPU-resurser och lagringsutrymme samtidigt. Kontrollera därför, förutom IO och IOPS, även SPEED och PMEM för samma tidsperiod, istället för att dra slutsatser om orsaken enbart utifrån varaktigheten. Om åtkomst sker från filcachen räknas den enligt CloudLinux inte in i IO-gränsen; den visade IO-användningen beskriver alltså inte varje filåtkomst på samma sätt.

Om en planerad uppgift kan skjutas upp, jämför dess normala genomförande under en mindre belastad period med en liknande tidigare period. Ta hänsyn till omfattningen och parallella uppgifter: en mindre import kan inte direkt jämföras med en fullständig säkerhetskopiering. Ytterligare belastningstester eller radering av filer är inte nödvändiga för denna bedömning.

Den Databasbelastning kan spela en roll, även om den visade webb-CPU-användningen är låg. Hur den tilldelas kontot och eventuella separata MySQL-gränser beror på konfigurationen. Fråga leverantören vilka databasvärden du kan se i kontrollpanelen och om databasaktiviteten räknas in i LVE eller begränsas separat.

Vid en supportförfrågan är det bra att ange domän, tidpunkt med tidszon, observerad HTTP-status och den berörda processen. Lägg till de gränsvärden, användningsvärden och fel som var synliga under samma tidsperiod, samt kända importer eller säkerhetskopior. Vänligen begär en kartläggning av gränshändelserna och, om möjligt, en utvärdering av processöversikter; på så sätt kan antagandet undersökas mer ingående.

Optimera, uppgradera eller byta server?

Börja med att Optimering en identifierad uppgift, om dess resursbehov kan minskas på ett begripligt sätt. Kontrollera till exempel cacheinställningar, tillägg och parallellt planerade bakgrundsjobb. Jämför därefter liknande tidsperioder och var uppmärksam på både användarproblemen och de berörda resursvärdena. En enskild ändring gör det lättare att se vad som faktiskt har förändrats.

En uppgradering är ett alternativ när återkommande, belagda toppar når de tilldelade gränserna trots lämplig optimering. Fråga först efter de konkreta värdena för SPEED, PMEM, IO, IOPS, EP och NPROC. Jämför inte bara paketnamnen: En högre CPU-gräns löser varken ett oberoende EP-begränsningsproblem eller brist på LVE-minne.

Till Prisjämförelse Detta ingår också i tillämpningsområdet. Meddela leverantören hur många webbplatser ditt konto innehåller och fråga om de använder en gemensam resursbudget eller om det finns gränser per webbplats. CloudLinux erbjuder med Isolates en möjlighet för det senare; men det framgår inte av produktnamnet i sig att din tjänst använder denna funktion.

En VPS eller en managed server kan ge större flexibilitet, men är inte automatiskt en lösning för alla långsamma webbplatser. Avgörande faktorer är de tillgängliga resurserna, den faktiska belastningen och driftsmodellen: När det gäller en VPS måste du framför allt klargöra vilka administrativa uppgifter du själv ska sköta; när det gäller en managed server, vilka uppgifter leverantören tar hand om.

Om orsaken förblir oklar är det bättre att ställa frågor utifrån de insamlade tidsangivelserna och felen än att byta ut utrustningen på grund av misstankar. Även under en LVE-gräns kan applikationer, nätverk eller databaser orsaka fördröjningar. Se till att få bekräftat vilka statistikuppgifter och vilken support som ingår i det aktuella erbjudandet innan du fattar ett beslut.