De LVE-limieten van CloudLinux bij shared hosting begrijpen en controleren

Wat een LVE bij shared hosting beperkt

Bij shared hosting delen meerdere klanten de resources van een server. CloudLinux kan het gebruik van een klantaccount met een Lichtgewicht gevirtualiseerde omgeving, kortweg LVE, beperken. De aanbieder bepaalt welke limieten gelden. Deze zijn bedoeld om te voorkomen dat een account onbeperkt gebruikmaakt van de beschikbare middelen; omgekeerd kan ook de eigen website tegen deze limieten aanlopen.

Een limiet geeft een bovengrens aan en betekent niet automatisch dat er een bepaalde prestatie wordt gegarandeerd. Een CPU-limiet houdt bijvoorbeeld niet in dat je exclusief over een processorkern beschikt of dat een bepaalde responstijd wordt gegarandeerd. Hoe snel een toepassing werkt, hangt ook af van de taak, de hardware en andere componenten.

Een LVE maakt van je hostingpakket ook geen eigen server. De provider blijft de gedeelde omgeving beheren en bepaalt de configuratie ervan. Als klant kun je de geldende instellingen en de gevolgen daarvan alleen zelf controleren voor zover je abonnement en het hostingpaneel de betreffende informatie verstrekken.

Dit moet worden onderscheiden van CageFS: Het gaat om de isolatie van het bestandssysteem, terwijl LVE-limieten het gebruik van systeembronnen beperken. Beide functies kunnen elkaar aanvullen, maar zijn niet hetzelfde. De aanbieder kan je bevestigen welke componenten in jouw pakket daadwerkelijk actief zijn.

Een uitgebreidere toelichting op de onderdelen vind je in het artikel over de Procesisolatie met CloudLinux SecureLVE. Voor het daadwerkelijk opsporen van fouten is de configuratie van je eigen pakket echter doorslaggevend: de interface en het detailniveau van de weergave van de bronnen kunnen per paneel en activering verschillen.

Voor wie gelden de limieten?

Niet alleen de hoogte van een limiet is van doorslaggevend belang, maar ook de Toepassingsgebied. Als je bijvoorbeeld een blog en een webwinkel onder hetzelfde hostingaccount beheert, kunnen beide in een accountgebonden configuratie gebruikmaken van hetzelfde budget aan resources. Een import in de webwinkel kan dan capaciteit in beslag nemen die de blog op datzelfde moment ook nodig heeft.

Dat betekent niet dat elke trage pagina wordt veroorzaakt door een ander project binnen het account. Het verklaart echter wel waarom je bij een grensgebeurtenis niet alleen naar het domein moet kijken dat op dat moment wordt beïnvloed. Ook geplande taken en andere websites van hetzelfde account kunnen in de betreffende periode van belang zijn.

CloudLinux documenteert met Isolaten daarnaast een mogelijkheid om beperkingen op websiteniveau in te stellen. Of deze functie wordt gebruikt en hoe de toewijzing in het betreffende aanbod eruitziet, kan niet worden afgeleid uit de benaming ‘CloudLinux’ alleen. Ook een afzonderlijke beoordeling is daarom geen vervanging voor het raadplegen van de concrete tariefvoorwaarden.

Vraag de aanbieder, voordat je tarieven vergelijkt, zo concreet mogelijk: gelden SPEED, PMEM, IO, IOPS, EP en NPROC per hostingaccount of per website? Als meerdere projecten één budget delen, is het bovendien belangrijk om te weten welke domeinen en taken aan dit budget zijn toegewezen. Zo voorkom je dat je per ongeluk een opgegeven waarde voor elke afzonderlijke website inplant.

Als het paneel slechts één algemene statistiek weergeeft, helpt dit in eerste instantie bij het afbakenen van de tijdsperiode, maar niet per se bij het toewijzen aan een specifieke toepassing. Vraag in dat geval de helpdesk om informatie over welke uitsplitsing beschikbaar is en of de belasting aan een project of een taak kan worden toegewezen.

Het verschil tussen CPU, geheugen en toegangslimieten

De verschillende limieten voor shared hosting leggen beperkingen op aan verschillende soorten activiteiten. SPEED staat voor het CPU-budget: als dit volledig wordt benut, worden rekenintensieve processen afgeremd en kunnen verzoeken meer tijd in beslag nemen. Een CPU-limiet bij hosting is dus slechts één mogelijke verklaring voor trage pagina’s en staat niet gelijk aan alle LVE-limieten.

PMEM beperkt het fysieke geheugen van de LVE. Bij geheugendruk kan eerst cache worden vrijgegeven; als dat niet voldoende is, kunnen processen worden beëindigd. Dit moet worden onderscheiden van de verouderde waarde VMEM voor virtueel geheugen. Hetzelfde geldt voor de PHP-memory_limit niet gelijk te stellen aan het volledige PMEM-budget van het LVE.

Bij bestandstoegang meten IO en IOPS verschillende zaken: IO heeft betrekking op de gegevensdoorvoer, IOPS op het aantal lees- en schrijfbewerkingen per seconde. Veel kleine bestanden kunnen daarom een andere limiet in beslag nemen dan enkele grote bestanden. IO verwijst hier niet naar de snelheid van je internetverbinding.

EP telt het aantal bezoeken aan de LVE en is geen algemene limiet voor het aantal gelijktijdige bezoekers. Hoe bezoeken worden geteld, hangt onder andere af van de webserver en het procesmodel. NPROC beperkt daarentegen het aantal processen en threads. Als deze limiet is bereikt, kunnen er tijdelijk geen nieuwe processen meer worden aangemaakt; EP en NPROC zijn daarom niet onderling uitwisselbaar.

Opslagruimte en inodes zijn verwante, maar afzonderlijke tariefgegevens. Een vol bestandsquotum of een bereikte inode-limiet is niet automatisch een CPU-, PMEM- of EP-probleem. Welke van deze waarden je zelf in het paneel ziet, hangt af van de provider en de aangeboden interface.

Een overzicht van LVE-limieten en de gevolgen daarvan

De LVE-limieten werken niet allemaal op dezelfde manier: sommige vertragen lopende werkzaamheden, andere verhinderen nieuwe processen of kunnen bestaande processen beëindigen. De tabel helpt je om een weergegeven resource te koppelen aan het bijbehorende gedrag en een passend controlespoor. De concrete limietwaarden worden door je provider vastgesteld.

Op PMEM-limiet Het gaat niet alleen om het geheugen van afzonderlijke applicatieprocessen. Ook gedeeld geheugen en de bestandscache kunnen worden meegeteld; of de cache wordt meegeteld, hangt af van de configuratie. Wanneer processen worden beëindigd, kunnen er HTTP-fouten optreden, maar dit hoeft niet per se het zichtbare gevolg te zijn.

De twee limieten voor bestandstoegang hebben betrekking op verschillende grootheden: IO beperkt de gegevensdoorvoer; IOPS staat voor het aantal bewerkingen. Veel kleine bestanden kunnen daarom vooral de IOPS belasten, terwijl grote bestanden een hoge doorvoer kunnen genereren. IO staat hier niet voor de netwerkbandbreedte; volgens CloudLinux tellen toegangen vanuit de bestandscache niet mee voor de IO-limiet.

De CPU-limiet berekenen aan de hand van een voorbeeld

Stel dat je pakket een Snelheidslimiet van 150 procent. Aangezien 100 procent rekenkundig overeenkomt met één processorkern, komt dit neer op een CPU-budget dat overeenkomt met anderhalve kern. Dit is een illustratief rekenvoorbeeld, geen meting. De werkelijke waarde van je pakket kan afwijken; de informatie van de aanbieder is doorslaggevend.

Dit voorbeeld beschrijft een bovengrens voor de beschikbare CPU-tijd, niet een reservering van een exclusieve kern. Het betekent ook niet dat elk afzonderlijk proces anderhalve kern tegelijkertijd kan gebruiken. Hoe het budget over lopende taken wordt verdeeld, hangt onder andere af van het aantal processen dat daadwerkelijk parallel rekenkracht nodig heeft.

150 procent betekent noch een gegarandeerde responstijd, noch een bepaald aantal bezoekers dat tegelijkertijd kan worden bediend. Een eenvoudige verzoek kan weinig rekenwerk vergen, terwijl een dynamisch verzoek daarentegen aanzienlijk meer rekenwerk kan vergen. Daarbij komen nog mogelijke wachttijden voor het openen van bestanden of databasewerk, die niet automatisch worden weggenomen door een hoger CPU-budget.

Zelfs identieke percentages op verschillende servers vormen geen directe snelheidsvergelijking: processorkernen kunnen qua prestaties van elkaar verschillen. Voor de beoordeling van je CPU-limiet is het daarom belangrijker of het gebruik tijdens een concreet probleem herhaaldelijk tegen de limiet aan zit en of er overeenkomstige grensgebeurtenissen zichtbaar zijn. Zelfs dan moet je nog andere mogelijke oorzaken onderzoeken.

De bronnenlijst correct lezen

Als je provider een overzicht van de resources heeft geactiveerd, begin dan met een incident dat zo nauwkeurig mogelijk is afgebakend. Noteer het domein, de datum, het tijdstip en de tijdzone, en indien van toepassing de weergegeven HTTP-status. Beschrijf ook wat traag was of niet werkte. Zonder deze gegevens is het moeilijk om een piek in de statistieken aan een concreet probleem te koppelen.

Selecteer vervolgens dezelfde periode in het scherm en vergelijk voor CPU, PMEM, IO, IOPS, EP en NPROC telkens het verbruik, de ingestelde limiet en, indien van toepassing, de weergegeven Fouten. Niet elk scherm geeft alle waarden op dezelfde manier weer. Als er statistieken ontbreken of als het onduidelijk is op welke rekening ze betrekking hebben, neem dan contact op met de aanbieder.

Let op de Tijdsresolutie: Een laag uurgemiddelde kan een korte piek verbergen waarbij een grens is bereikt. Kies, indien beschikbaar, een kortere periode of een gedetailleerdere weergave. Vergelijk de piek met de genoteerde fouttijd, in plaats van alleen op basis van een dag- of uurgemiddelde te concluderen dat er geen bottleneck was.

Fouten duiden op grensgevallen, maar zijn geen directe telling van getroffen bezoekers of mislukte paginaweergaven. Een fout die qua tijd overeenkomt, is een aanwijzing, maar nog geen volledig bewijs van de oorzaak. Controleer daarom ook of er op hetzelfde moment een import, een back-up, een geplande taak of een wijziging aan de applicatie plaatsvond.

De interface en de functies ervan zijn afhankelijk van het paneel en de activering; er is daarom geen algemeen geldend menupad. Voor de technische achtergrond van het beheer biedt het artikel over de CloudLinux LVE Manager en voor het beheer van systeembronnen meer informatie. Voor de administratieve configuratiestappen zijn echter de juiste rechten vereist en deze zijn niet automatisch beschikbaar voor je klantenaccount.

Trage pagina’s en fouten indelen

Als je CMS traag reageert tijdens het bewerken of bij het dynamisch laden van pagina’s, vergelijk dan eerst de betreffende periode met de CPU-weergave. Als het gebruik herhaaldelijk de SPEED-limiet bereikt en er bijbehorende fouten zichtbaar zijn, is een CPU-beperking aannemelijk. Het feit dat de tijdstippen overeenkomen, maakt het tot een aanwijzing, maar bewijst nog niet welke activiteit de belasting heeft veroorzaakt.

Controleer bijvoorbeeld of er op hetzelfde moment geplande taken worden uitgevoerd of dat een wijziging in uitbreidingen samenvalt met het probleem. Ook databasewerkzaamheden, netwerkproblemen of een traag reagerende externe interface kunnen pagina’s vertragen. Een hoge CPU-belasting op zich betekent daarom niet dat het tarief verkeerd is gekozen, noch dat een bepaalde uitbreiding de oorzaak moet zijn.

Als er fouten optreden bij meerdere gelijktijdig binnenkomende dynamische verzoeken, kan een gelijktijdige EP-fout hulp bieden. Langdurige verzoeken houden de poorten langer bezet; tegelijkertijd kan een bezoeker meerdere verzoeken genereren. EP is daarom geen bezoekerstelling. Bij Apache is HTTP 508 een mogelijk gevolg van het overschrijden van de EP-limiet, maar de status op zich bewijst nog niet de oorzaak.

Als tijdens een import PMEM-fouten worden weergegeven, kan de LVE-geheugenlimiet de oorzaak zijn. Naast de import kunnen ook gelijktijdig draaiende PHP-processen geheugen in beslag nemen; zonder de juiste procesgegevens blijft het onduidelijk welke taak de doorslag heeft gegeven. Ook een HTTP-500- of 503-fout kan andere oorzaken hebben en is op zichzelf geen bewijs van een tekort aan geheugen.

De PHP-waarde memory_limit Dit geeft geen volledig antwoord op deze vraag: het geeft geen overzicht van het totale geheugengebruik van alle taken in het LVE. Vergelijk daarom het tijdstip van de import met het PMEM-gebruik en de fouten, en noteer welke andere taken tegelijkertijd draaiden, voordat je een instelling of het tarief wijzigt.

De achtergrondbelasting controleren en ondersteuning inschakelen

Als een back-up of bestandsimport traag verloopt, kijk dan eens naar IO en IOPS apart. IO beperkt de gegevensdoorvoer bij toegang tot harde schijven, IOPS het aantal lees- en schrijfbewerkingen per seconde. Veel kleine bestanden kunnen daarom een andere limiet vereisen dan de overdracht van een klein aantal grote bestanden; IO is in dit geval niet de internetbandbreedte.

Een back-up kan tegelijkertijd CPU en geheugen belasten. Controleer daarom naast IO en IOPS ook SPEED en PMEM voor dezelfde periode, in plaats van de oorzaak uitsluitend af te leiden uit de duur. Als toegangen vanuit de bestandscache worden afgehandeld, tellen deze volgens CloudLinux niet mee voor de IO-limiet; het weergegeven IO-gebruik geeft dus niet elke bestandstoegang op dezelfde manier weer.

Als een geplande taak kan worden uitgesteld, vergelijk dan de normale uitvoering ervan in een minder drukke periode met een vergelijkbare eerdere periode. Houd daarbij rekening met de omvang en gelijktijdig lopende taken: een kleinere import is niet direct vergelijkbaar met een volledige back-up. Extra productieve belastingstests of het verwijderen van bestanden zijn voor deze beoordeling niet nodig.

De Database laden kan een rol spelen, zelfs als het weergegeven CPU-gebruik van de website laag is. De toewijzing aan het account en eventuele afzonderlijke MySQL-limieten zijn afhankelijk van de configuratie. Vraag de provider welke databasestatistieken je in het paneel kunt zien en of databasewerk wordt meegeteld bij de LVE of apart wordt beperkt.

Voor een supportaanvraag zijn het domein, het tijdstip met tijdzone, de waargenomen HTTP-status en het betreffende proces nuttige gegevens. Voeg hieraan de limieten, gebruikswaarden en fouten toe die in dezelfde periode zichtbaar waren, evenals bekende imports of back-ups. Geef de toewijzing van de grensgebeurtenissen op en, indien beschikbaar, een analyse van proces-snapshots; zo kan het vermoeden gerichter worden onderzocht.

Optimaliseren, upgraden of van server wisselen?

Begin met de Optimalisatie een geïdentificeerde taak, als de benodigde resources op een aantoonbare manier kunnen worden verminderd. Controleer bijvoorbeeld cache-instellingen, extensies en parallel geplande achtergrondtaken. Vergelijk vervolgens vergelijkbare periodes en let zowel op de gebruikersproblemen als op de betrokken resourcewaarden. Een enkele wijziging maakt het daarbij gemakkelijker te herkennen wat er daadwerkelijk is veranderd.

Een upgrade is een alternatief wanneer terugkerende, gedocumenteerde pieken ondanks adequate optimalisatie tegen de toegewezen limieten aanlopen. Vraag vooraf naar de concrete waarden voor SPEED, PMEM, IO, IOPS, EP en NPROC. Vergelijk niet alleen de pakketnamen: een hogere CPU-limiet lost noch een onafhankelijk bestaande EP-limiet, noch een tekort aan LVE-geheugen op.

Naar de Tariefvergelijking daaronder valt ook het toepassingsgebied. Geef de aanbieder door hoeveel websites je account bevat en vraag of ze gebruikmaken van een gezamenlijk budget voor bronnen of dat er limieten per website gelden. CloudLinux biedt met ‘Isolates’ een mogelijkheid voor dat laatste; uit de productnaam alleen blijkt echter niet dat jouw pakket hiervan gebruikmaakt.

Een VPS of managed server kan meer flexibiliteit bieden, maar is niet automatisch de oplossing voor elke trage website. Doorslaggevend zijn de beschikbare resources, de daadwerkelijke belasting en het bedrijfsmodel: bij een VPS moet je vooral duidelijk maken welke beheeractiviteiten je zelf op je neemt; bij een managed server, welke taken de provider voor zijn rekening neemt.

Als de oorzaak onduidelijk blijft, is het zinvoller om navraag te doen met de verzamelde tijdstippen en fouten dan om op basis van vermoedens over te stappen. Ook onder een LVE-limiet kunnen de applicatie, het netwerk of de database voor vertraging zorgen. Vraag, voordat je een beslissing neemt, na welke statistieken en ondersteuning in het betreffende aanbod beschikbaar zijn.