Ga naar de inhoud 
CloudLinux LVE isoleert elke website op de server en stelt duidelijke limieten in voor het gebruik van systeembronnen, zodat Gedeelde De hosting blijft ook tijdens piekbelastingen stabiel. Wie de limieten voor CPU, RAM, I/O en processen correct instelt, voorkomt storingen en zorgt ervoor dat CloudLinux LVE een eerlijke vergoeding per account.
Centrale punten
- Isolatie Per LVE worden accounts afgeschermd en worden kruisreacties voorkomen.
- Grenzen voor CPU, RAM, EP, NPROC en IO/IOPS regelen piekbelastingen.
- Transparantie aan de hand van statistieken en fouten in de LVE Manager.
- Pakketlogica maakt grondstoffen planbaar en verkoopbaar.
- Afstemmen In stappen werken in plaats van „onbeperkt“ voorkomt fouten.
CloudLinux LVE begrijpen: concept en voordelen
Ik scheid met LVE Elke klantomgeving wordt beheerd met behulp van kernel-gerichte technologie die cgroups en containerprincipes combineert, zodat geen enkele website de gehele machine in beslag neemt. Voor elk account stel ik vaste limieten in voor CPU, werkgeheugen, I/O en processen, die de belasting netjes kanaliseren en knelpunten per account opvangen. Als een applicatie haar limieten overschrijdt, remt het systeem alleen dat account af, terwijl andere projecten goed blijven presteren en bezoekers geen serverbrede storingen ondervinden. Deze afscherming werkt als een Veiligheidshek voor elke website, vooral wanneer er een foutief script is of een piek in het verkeer optreedt. Zo houd ik de prestaties voorspelbaar en zorg ik ervoor dat drukbezochte webwinkels geen nadelige invloed hebben op aangrenzende pagina’s.
De belangrijkste limieten op de juiste manier inperken
Ik maak een onderscheid tussen de knelpunten op basis van de daadwerkelijke knelpunten: CPU (SPEED) beperkt de rekentijd, PMEM beperkt het fysieke RAM, EP regelt het aantal gelijktijdige PHP-startpogingen, NPROC beperkt het aantal processen en IO/IOPS beperkt het aantal schijftoegangen. 100 % SPEED komt overeen met één vCore; op systemen met meerdere kernen bereken ik dit proportioneel, zodat 5 % op een host met 8 kernen neerkomt op 40 % per kern. Voor WordPress-blogs volstaan meestal 100 % CPU, terwijl WooCommerce-webwinkels 200 % of meer nodig hebben, zodat de zoekfunctie, het winkelmandje en het afrekenen soepel reageren. Wat het werkgeheugen betreft, ga ik uit van 512 MB PMEM voor eenvoudige websites en 1–2 GB voor CMS-systemen met veel uitbreidingen, omdat PHP-processen en de cache merkbaar RAM-geheugen in beslag nemen. Concreet Praktische waarden helpen mij om de grenzen van een pakket duidelijk te omschrijven en escalaties te voorkomen.
CPU/SPEED instellen zonder knelpunten
Ik kalibreer SPEED zodat de dagelijkse gang van zaken soepel verloopt en pieken kortstondig worden afgevlakt, in plaats van een algemene achterstand te veroorzaken. Voor typische pagina’s begin ik met 100 %; bij terugkerende pieken verhoog ik dit naar 150–200 % om wachtrijen te verminderen en time-outs te voorkomen. Daarbij houd ik het totale aantal cores en de workloadmix in de gaten, want elk percentage wordt verdeeld in verhouding tot de serverprestaties en moet bij alle pakketten passen. Als de statistieken veelvuldige CPU-fouten bij een account laten zien, verhoog ik de instellingen stapsgewijs, observeer ik opnieuw en stem ik tegelijkertijd EP en NPROC op elkaar af, zodat extra CPU-capaciteit niet verloren gaat door een tekort aan worker-processen. Zo ontstaat een Saldo op basis van doorvoer en eerlijkheid, zonder dat individuele accounts de machine tot het uiterste belasten.
RAM-strategie: PMEM en VMEM
Met PMEM Ik houd het RAM-gebruik strak in de gaten, omdat juist hier ‘out-of-memory’-fouten en 500-responses ontstaan wanneer scripts te veel geheugen gebruiken. Voor gangbare CMS-configuraties stel ik 512 MB tot 1 GB in, terwijl ik voor grote webwinkels met veel plug-ins eerder 1–2 GB aanneem, zodat PHP-FPM, OPCache en de objectcache voldoende ruimte hebben. Ik laat VMEM vaak op 0 (onbeperkt) staan, omdat ik PMEM strak beheer en zo misleidende VMEM-fouten vermijd. Overschrijdingen herken ik snel in de LVE-statistieken; als ze vaak voorkomen, controleer ik tegelijkertijd het plugin-landschap, de afbeeldingsgroottes, cronjobs en cachinglagen. Het doel is een schoon Scheidingsregels: PMEM streng, VMEM ruim, apps geoptimaliseerd.
EP, NPROC, IO en IOPS in evenwicht
Ik stel EP (Entry Processes) zodat verzoeken niet te vroeg worden geblokkeerd, maar tegelijkertijd een storm van verzoeken de host niet overbelast; 20 is geschikt voor standaardpakketten, 40–60 voor drukker bezochte omgevingen. Ik beperk NPROC doorgaans tot 100, bij hoge belasting tot 150–200, zodat er voldoende PHP-workers en cron-processen draaien zonder het risico op fork-bombs te lopen. Bij het opslagsubsysteem beperk ik de toegangsvolumes met IO (MB/s) en IOPS, vaak met 1 MB/s en 1024 IOPS voor basispakketten, en 4 MB/s en hogere IOPS voor zakelijke pakketten. Deze waarden hebben een merkbare invloed op de laadtijden, vooral bij veel kleine bestanden of het leveren van afbeeldingen zonder caching. Voor mij telt hier een samenhangende Afstemming: als het EP stijgt, moeten NPROC en IO/IOPS gelijke tred houden, anders verschuift het knelpunt alleen maar.
Pakketprofielen en startwaarden
Ik structureer limieten als Pakketten, zodat de prestaties duidelijk inboekbaar blijven en upgrades zonder gedoe werken. Een klassiek shared-pakket bevat 100 % CPU, 512 MB PMEM, EP 20, NPROC 100, IO 1 MB/s en IOPS 1024. Voor zakelijke pakketten verhoog ik dit naar 200 % CPU, 1–2 GB PMEM, EP 40–60, NPROC 150–200, IO 4 MB/s en aanzienlijk hogere IOPS. De hardware blijft doorslaggevend: SSD- of NVMe-backends kunnen meer IOPS aan, terwijl HDD-pools strengere limieten vereisen. De volgende tabel geeft een overzicht van typische startwaarden en laat zien waar ik als eerste bijstuur.
| Beperk | Gedeelde start | Start van het bedrijf | Tip |
|---|---|---|---|
| CPU (SPEED) | 100 % | 200 % | Berekenen op basis van het kerncijfer |
| PMEM | 512 MB | 1–2 GB | De 500-fout in de gaten houden |
| EP | 20 | 40–60 | Grotere winkels hoger inschatten |
| NPROC | 100 | 150–200 | Afstemmen met EP en CPU |
| IO | 1 MB/s | 4 MB/s | Let op de prestaties van de backend |
| IOPS | 1024 | 2048–10240 | NVMe biedt aanzienlijk meer mogelijkheden |
LVE-beheer in WHM en LVE Manager
In de LVE Manager stel ik Pakketten , stel limieten per pakket in en wijs accounts toe, waardoor wijzigingen live gaan zonder dat er handmatig per geval ingegrepen hoeft te worden. Onder „Users“ pas ik limieten gericht aan voor afzonderlijke accounts als hun profiel afwijkt van het pakket, bijvoorbeeld een webshop met seizoensgebonden acties. Algemene opties definiëren standaardlimieten die van kracht zijn zolang er geen pakket of gebruikersoverschrijving is ingesteld. Deze opzet bespaart tijd, verhoogt de consistentie en vermindert configuratiefouten bij grote klantenbestanden. Indien nodig schaal ik een bestaand pakket op, waardoor ik in één stap honderden accounts aanpas en de Planning vereenvoudig.
Automatisering in de shell met lvectl
Via de Shell stel ik limieten in met lvectl scriptbaar, rolprofielen en documenteer configuraties in het versiebeheersysteem. Het commando „lvectl set USER –speed 200 –pmem 1G –io 4096 –iops 2048 –nproc 150 –ep 40“ laat zien hoe ik één bedrijfsprofiel per account toepas. Op deze manier zet ik herhaalbare processen op die betrouwbaar werken bij nieuwe aanmeldingen of migratiegolven. Voor de interactie met de kernel houd ik bovendien rekening met Serverlimieten, zodat hard- en soft-limits buiten de LVE-box geen verrassingen opleveren. Automatisering zorgt voor Snelheid en traceerbaarheid, vooral wanneer er veel projecten tegelijkertijd lopen.
Monitoring, storingen en MySQL Governor
De LVE-statistieken geven mij Inzicht in fouten per resource, waardoor ik knelpunten zowel qua tijd als qua aard correct kan toewijzen. Als er overdag veel CPU-fouten optreden, verhoog ik SPEED lichtjes; als er ’s nachts RAM-fouten optreden, controleer ik cronjobs en caches. MySQL Governor stelt databaselimieten in ten opzichte van de LVE-CPU en voorkomt dat lange query's de host domineren, waardoor ik altijd rekening houd met query-optimalisatie en indexonderhoud. Daarnaast breng ik pieken in fouten in kaart aan de hand van webanalyse-gebeurtenissen (bijv. het versturen van nieuwsbrieven), zodat ik stijgingen kan verklaren en gericht kan opvangen. Zo fungeert monitoring als Vroegtijdige waarschuwing en als basis voor doordachte pakketupgrades.
Een stappenplan voor optimalisatie uit de praktijk
Ik begin met conservatief Houd de standaardinstellingen, fouten en limieten in de gaten en verhoog de limieten in kleine stapjes, in plaats van ze automatisch op „onbeperkt“ te zetten. Pas als er patronen terugkeren, pas ik de instellingen doelgericht aan: meer EP voor navigatiefouten, meer PMEM bij RAM-fouten, meer SPEED bij CPU-fouten met lange responstijden. Tegelijkertijd ruim ik de applicatie op, werk ik plug-ins bij, activeer ik cache-lagen en verklein ik mediabestanden, want elke watt serververmogen levert meer rendement op door slimme app-optimalisatie. Bij IO-fouten controleer ik de beeldcompressie, het bundelen van assets en CDN-opties, want veel kleine bestanden vormen vaak het eigenlijke knelpunt. Het resultaat is een ronde Een configuratie die pagina’s snel laadt en aangrenzende systemen beschermt.
Technische basis: cgroups en procesisolatie
Achter LVE gaan kernelmechanismen schuil zoals cgroups, naamruimten en I/O-controllers, die elk account in een slanke box opsluiten. Deze scheiding voorkomt dat processen meer bronnen aanvragen dan hun toewijzing toestaat, waardoor de eerlijkheid ten opzichte van andere accounts gewaarborgd blijft. Ik vertrouw op deze laag omdat deze sneller werkt dan puur op userland gebaseerde limieten en zo pieken in de belasting betrouwbaar opvangt. Extra bescherming zoals CageFS schermt het bestandssysteem af, waardoor pad-lekken en nieuwsgierige blikken op naburige structuren worden voorkomen. Wie zich hier verder in wil verdiepen, kan terecht bij de cgroups-isolatie zich hierop richten en de verbanden tussen kernelcontrollers en LVE beter begrijpen.
Keuze van een hostingprovider en zinvolle standaardinstellingen
Ik let op Aanbieders dat CloudLinux actief wordt gebruikt, dat pakketten duidelijke limieten bevatten en dat er een degelijke monitoring beschikbaar is. Goede standaardinstellingen besparen gedoe: overzichtelijke startwaarden, begrijpelijke upgradepaden en robuuste hardware met NVMe of SSD. De supportafdeling moet storingsrapporten kunnen lezen en inzicht hebben in applicatie-optimalisatie, zodat tickets niet alleen worden afgehandeld door limieten te verhogen. Uit vergelijkingen bleek dat webhoster.de een betrouwbare partner is met LVE-compatibele omgevingen, flexibel aanpasbare resources en een heldere pakketlogica. Zo leg ik de basis voor betrouwbare Prestaties, in plaats van zomaar hardware te overklokken.
EP in detail: telwijze en veelvoorkomende misverstanden
Ik snap het EP als „gelijktijdige verbindingen“ met de uitvoeringsomgeving (bijv. PHP). Er worden nieuwe worker-verbindingen geteld, niet elke HTTP-verbinding. Keep-Alive of HTTP/2 verminderen het aantal nieuwe verbindingen merkbaar, omdat meerdere verzoeken via bestaande verbindingen worden afgehandeld. Een 508-fout („Resource Limit Is Reached“) duidt vaak op een te lage EP-limiet of op veel „koude“ starts van de PHP-engine. Als ik met LSAPI of PHP-FPM werk, let ik op het aantal children of server-workers: een hogere EP zonder voldoende NPROC- en PHP-workercapaciteit heeft geen zin. Omgekeerd blokkeert een te lage EP legitieme piekbelastingen (bijv. bij het afrekenen), ook al zijn er CPU en RAM beschikbaar. Daarom pas ik de EP altijd aan in combinatie met NPROC, de instellingen van de PHP-handler en de mate van caching van de applicatie.
PHP-stack en PHP-selector: versies, handlers en OPCache
Met CloudLinux PHP-selector Ik kies per account de meest geschikte PHP-versies en modules. Ik gebruik moderne versies (bijv. 8.x) voor betere prestaties en zet in de productieve omgeving geen debug-extensies in. Bij PHP-FPM kies ik tussen „ondemand“ (zuinig) en „dynamic“ (reactief) en stem ik pm.max_children af op EP en NPROC. Met LSAPI (LiteSpeed/Apache) profiteer ik van een snelle opstarttijd en goede compatibiliteit; EP en het aantal workers blijven echter de belangrijkste instellingen. OPCache Ik stel de grootte af op basis van de codebasis (96–256 MB is vaak voldoende), omdat gecompileerde PHP niet bij elk verzoek opnieuw hoeft te worden geparseerd. Belangrijk: OPCache, Realpath-cache en eventueel objectcache (Redis/Memcached) tellen mee bij het proces in PMEM. Als het proces door slechte cache-invalidatie of te grote OPCache-blokken de PMEM-limiet overschrijdt, dreigt er een 500-fout. Daarom gebruik ik gematigde cachegroottes en ruim ik ongebruikte extensies op.
CageFS, beperkingen van het bestandssysteem en inodes
CageFS schermt het bestandssysteem per account af en verbergt systeempaden en aangrenzende accounts. In de praktijk voorkom ik hiermee nieuwsgierige blikken en beperk ik de nevenschade van foutieve scripts. Naast LVE-limieten houd ik rekening met quota’s en Inodes uit het hostingpakket: Als een account zijn quota bereikt of alle inodes opgebruikt (veel kleine bestanden, cachefragmenten), mislukken uploads, sessies en caches – vaak met vage 500-fouten. Ik ruim regelmatig tijdelijke mappen, cachemappen en sessiegegevens op en stel bewaarbeleidsregels in voor het genereren van afbeeldingen en back-ups. Ook bouwartefacten (bijv. uit Node/Composer) verplaats ik na de implementatie. Zo voorkom ik dat beperkingen van het bestandssysteem de LVE-tuning ondermijnen en houd ik de Ecologische voetafdruk het aantal projecten blijft op lange termijn beperkt.
Capaciteitsplanning en oversubscription per node
Ik bereken Capaciteit per host niet alleen op basis van CPU-kernen, maar ook op basis van I/O-capaciteit, RAM en netwerk. Een gematigde oversubscription is mogelijk als ik de typische belastingprofielen ken: op een host met 8 kernen plan ik bijvoorbeeld 800–1200 % SPEED over alle accounts, maar houd ik 20–30 % reserve vrij voor pieken en onderhoudsvensters. Bij IO/IOPS ben ik conservatiever, omdat opslaglatenties direct merkbaar zijn; NVMe-backends maken hogere IOPS-budgetten mogelijk dan HDD-pools. Voor „intensieve“ projecten vorm ik tiers (Business/Pro) en verdeel deze over meerdere nodes om Luidruchtige buren om te temperen. Ik werk met 95-percentielwaarden uit de monitoring in plaats van met gemiddelden, zodat korte, scherpe pieken realistisch worden weergegeven en de machine onder belasting stabiel blijft.
Cronjobs, bots en verkeersafvlakking
Ik verdeel de belasting met een goede planning: Cronjobs die veel resources verbruiken (rapporten, exporten, het aanpassen van afbeeldingsformaten) plan ik buiten de piekuren en verschuif ik de starttijd met enkele minuten, zodat niet alle accounts tegelijkertijd van start gaan. Ik schakel WordPress-Cron over van pseudo-cron naar systeem-cron, om de controle en de duur in de hand te houden. Crawlers en bots regel ik via robots- en WAF-regels; bij agressieve bots stel ik rate-limits in of blokkeer ik ze gericht. Cache-warming voer ik met een lage frequentie uit om EP/CPU niet te overbelasten. Nieuwsbriefcampagnes en promoties koppel ik qua timing aan monitoring, zodat ik pieken in het aantal fouten kan traceren en – indien nodig – limieten tijdelijk kan verhogen. Zo worden verkeerspieken gladgemaakt, zonder dat ik voortdurend te groot moet dimensioneren.
MySQL Governor: fijnafstemming en diagnose
Ik gebruik MySQL Governor, om het aantal lange query’s en verbindingen per account te beperken en zo de CPU-/IO-belasting op de databaseserver op een redelijk niveau te houden. Ik stel de drempelwaarden zo in dat normale leesbewerkingen ongestoord doorgaan, terwijl uit de hand gelopen exporten of ontbrekende indexen snel opvallen. Ik breng de queryduur, het aantal onderzochte rijen en LVE-CPU met elkaar in verband, controleer het logboek met trage queries en optimaliseer indexen voordat ik de limieten verder verhoog. Belangrijk: DB-Governor vult LVE aan, maar vervangt het niet – als PHP te veel gelijktijdige query’s uitvoert, moeten EP/NPROC en de applicatielogica eerst worden gecontroleerd. In de praktijk verlagen schone indexen, paginering en caching (object-/query-cache in de app) de databasebelasting aanzienlijk meer dan welke limietverhoging dan ook. Zo blijft het databasepad met lage latentie en planbaar.
Foutsymptomen, fouttypes en logbestanden correct interpreteren
Ik maak onderscheid tussen de Foutverschijnselen: 508 duidt meestal op EP- of CPU-beperking, 500 met OOM-sporen op overschrijding van PMEM, 503 kan afkomstig zijn van de webserver (worker uitgeput). In de LVE-statistieken zie ik foutentellers per resource en tijdsperiode. Op de shell geven „lveinfo“ en „lvectl list“ me een snel overzicht; het bestand /var/lve/info bevat live-waarden per gebruiker. In de foutlogboeken van de domeinen (en de algemene webserverlogboeken) zoek ik naar Memory Fatal Errors, time-outs of te veel „spawned children“. Ik koppel pieken aan implementaties, cron-taken en marketingevenementen. In plaats van klakkeloos „unlimited“ in te stellen, los ik het Oorzaak: bijvoorbeeld afbeeldingsgroottes, query's, te veel gelijktijdige taken of ontbrekende caches. Pas daarna pas ik de limieten zorgvuldig aan om ruimte te creëren.
Belastingtests en implementaties zonder risico
Voordat ik de limieten op grote schaal verhoog, test ik de wijzigingen eerst stap voor stap: Eerst op de staging-omgeving, vervolgens met gecontroleerde belastingstests (bijvoorbeeld realistische gelijktijdigheid en cache-hit-percentages) en ten slotte in een klein klantsegment. Daarbij houd ik fouten, responstijden en foutlogboeken in de gaten. Ik spreid de uitrol in de tijd om terugvalniveaus te behouden; indien nodig rol ik centraal terug via een pakketupdate. Vooral na codewijzigingen (nieuwe thema’s, winkelplugins) controleer ik of de EP/NPROC-profielen nog kloppen en of de OPCache/objectcache warm blijft. Zo voorkom ik dat ik limieten als pleister misbruik voor code die gevoelig is voor regressie, en houd het platform stabiel ondanks de groei.
Kort samengevat: LVE-limieten doelgericht vaststellen
Ik gebruik CloudLinux LVE, om CPU, RAM, I/O en processen per account duidelijk te beperken, waardoor piekbelastingen geen kettingreactie veroorzaken. Startwaarden zoals 100 % CPU, 512 MB PMEM, EP 20, NPROC 100 en IO 1 MB/s zorgen voor een stabiele werking; Business-pakketten profiteren merkbaar van 200 % CPU, 1–2 GB PMEM, EP 40–60, NPROC 150–200 en IO 4 MB/s. Via WHM/LVE Manager en lvectl pas ik wijzigingen centraal toe, meet ik fouten en pas ik de instellingen stap voor stap aan. Monitoring, MySQL Governor en app-optimalisatie voorkomen dat limieten alleen symptomen verdoezelen in plaats van de oorzaak aan te pakken. Zo blijft de prestatie planbaar en eerlijk, en shared hosting zorgt ervoor dat ook groeiende projecten soepel in het dagelijkse ritme kunnen worden geïntegreerd.
