Ga naar de inhoud 
Ik laat je zien hoe je de CloudLinux LVE Manager in shared hosting correct configureert en de belangrijkste cloudlinux lve Limieten op een verstandige manier instellen. Zo kun je de CPU, het RAM-geheugen, de I/O en de processen per account gericht beheren, knelpunten voorkomen en ervoor zorgen dat buren geen uitschieters veroorzaken.
Centrale punten
Voordat ik in detail treed, zal ik de belangrijkste beslissingen samenvatten die bepalend zijn voor een constante kwaliteit van de hosting.
- VMEM uit: Geheugen alleen via PMEM beperken
- CPU realistisch: minimaal 100 %, vaak 200 %
- IO/IOPS: Waarden afstemmen op opslag (SATA/SSD/NVMe)
- EP/NPROC: voldoende speelruimte tegen 503-fouten
- Controle: Fouten in de gaten houden, limieten bijstellen
LVE Manager snel instellen: toegang en basisconfiguratie
Ik log in op WHM als root en open het item „CloudLinux Manager“ of „CloudLinux LVE Manager“, afhankelijk van de versie van het paneel, om de Oppervlak te activeren. Als de vermelding ontbreekt, installeer ik het pakket lvemanager of voer ik bij nieuwe installaties het script cldeploy uit, dat de kernel, LVE-componenten en lvestats activeert. Vervolgens controleer ik of statistieken worden bijgehouden en of nieuwe accounts automatisch de standaardlimieten krijgen. In Plesk of DirectAdmin ga ik op dezelfde manier te werk, omdat de UI-elementen en functies sterk op elkaar lijken. Pas wanneer de Manager zichtbaar is, de diensten actief zijn en de LVE-statistieken zijn gevuld, begin ik met de daadwerkelijke limietplanning en documentatie van de Standaard.
De juiste limieten kiezen: SPEED, PMEM, IO, IOPS, EP, NPROC
Ik begin met SPEED, omdat CPU-beperkingen websites direct vertragen, en stel minimaal 100 % in, meestal 200 % voor gangbare CMS-systemen, zodat piekbelastingen niet onmiddellijk effect hebben en de Prestaties constant blijft. Ik definieer PMEM als de maatgevende geheugenlimiet en schakel VMEM volledig uit, omdat virtueel geheugen onnauwkeurig lijkt te werken en valse alarmen veroorzaakt. IO stel ik in op MB/s en pas de waarde aan de opslag aan: op SATA eerder conservatief, op NVMe ruimer. IOPS beperk ik tegen zeer veel kleine toegangen, wat belangrijk is op dynamische pagina’s met veel bestanden. EP houd ik zo hoog dat er bij kortstondige pieken geen 503-fouten optreden, en NPROC beschermt tegen te veel processen door cronjobs of foutieve scripts, zodat de Serverbelasting voorspelbaar blijft. Deze beknopte handleiding helpt mij om dit in de praktijk in te delen LVE-limieten instellen.
Startwaarden en beproefde standaardinstellingen voor shared hosting
Ik schakel VMEM standaard uit en beheer het geheugen uitsluitend via PMEM, omdat ik daarmee beter voorspelbare resultaten bereik en foutmeldingen vermijd die bij het uitwisselen van geheugen zouden kunnen ontstaan; deze stap vormt de basis voor voorspelbaar Beheer van hulpbronnen. Als startwaarden stel ik meestal 100–200 % CPU, 1–2 GB PMEM, 5–10 MB/s IO, 1024–4096 IOPS, 20–40 EP en 100–200 NPROC, waarbij premium-pakketten hogere I/O- en CPU-budgetten krijgen. Op bijzonder snelle NVMe-systemen verhoog ik de IO/IOPS zonder andere klanten te hinderen, mits het totale systeem voldoende reserves heeft. Ik beschouw deze startwaarden niet als definitief, maar als uitgangspunt voor meting, evaluatie en bijsturing. Ik beoordeel storingen, seizoensgebonden patronen en workloads afhankelijk van het type toepassing en verschuif de grenswaarden geleidelijk totdat ze aansluiten bij de werkelijke profielen, waarmee ik Smoren Gebeurtenissen op een weloverwogen manier beperken.
| Tariefsoort | CPU (SNELHEID) | PMEM | IO | IOPS | EP | NPROC |
|---|---|---|---|---|---|---|
| Basis (blog/portfolio) | 100 % | 1 GB | 5 MB/s | 1024 | 20 | 100 |
| Zakelijk (MKB-site) | 200 % | 2 GB | 10 MB/s | 4096 | 30 | 150 |
| E-commerce (webwinkel) | 300 % | 4 GB | 20 MB/s | 8192 | 40 | 200 |
| Agentschap/wederverkoper (per klant) | 200 % | 2 GB | 15 MB/s | 6144 | 40 | 200 |
Pakketten aanmaken in de LVE Manager en koppelen aan Panel-pakketten
Ik structureer de LVE-pakketten eerst op basis van klanttypes, zodat de limieten per niveau consistent worden toegepast en ik upgrades kan doorvoeren zonder dat ik deze handmatig hoef bij te werken; dat maakt mijn werk Steun merkbaar. In het overzicht „Packages“ maak ik Basis-, Business- en E-commerce-profielen aan met de hierboven genoemde waarden. In WHM open ik vervolgens „Edit a Package“, scroll naar ‘CloudLinux LVE Settings’ en koppel per cPanel-pakket het bijbehorende LVE-profiel, zodat nieuwe en bestaande accounts de limieten automatisch overnemen. Deze koppeling is cruciaal om ervoor te zorgen dat verkooppakketten en de techniek op één lijn blijven en klanten voorspelbare resources krijgen. Als klanten speciale eisen hebben, schaal ik op naar een hoger pakket of pas ik tijdelijk per account aan, zonder de tarieflogica te verlaten, wat de Consistentie bewaard.
Individuele aanpassingen doorvoeren en limieten voor resellers instellen
Ik open het gebruikersoverzicht in de LVE Manager, selecteer het doelaccount en pas SPEED, PMEM, IO, IOPS, EP en NPROC direct aan wanneer een project op korte termijn meer budget nodig heeft; zo los ik piekbelastingen op zonder het hele platform te wijzigen, wat de Flexibiliteit verhoogd. Voor resellers activeer ik „Manage Limits“ op het reseller-account en wijs ik een eigen quotum toe, dat de reseller onder zijn klanten verdeelt. Zo blijft de reseller binnen zijn limiet, terwijl ik als beheerder de bovengrens waarborg. Bij promoties of seizoensgebonden pieken (bijv. feestdagen) plan ik tijdelijke verhogingen en zet ik daarna de oorspronkelijke waarden weer terug. Deze werkwijze zorgt voor transparantie en voorkomt discussies over vage „traagheid“, omdat ik cijfers, fouten en tijdsperioden duidelijk kan benoemen, wat de Traceerbaarheid versterkt.
Monitoren, analyseren, bijsturen: LVE-statistieken correct interpreteren
Ik bekijk in de LVE-statistieken per gebruiker het gebruik en de foutmeldingen, en let daarbij vooral op terugkerende pieken in CPU-, geheugen- of I/O-gebruik, omdat deze wijzen op de noodzaak van aanpassingen aan de configuratie en de Capaciteit beïnvloeden. In cPanel verwijs ik klanten naar „Resource Usage“, zodat ze hun eigen situatie kunnen bekijken en zelf plug-ins of taken kunnen optimaliseren. Voordat ik strikte limieten instel, verzamel ik een paar dagen lang meetgegevens om ruis van patronen te onderscheiden. Daarna pas ik de limieten in kleine stapjes naar boven of beneden aan en controleer ik de effecten opnieuw. Als ik op nieuwere distributies met een andere controller-indeling werk, houd ik rekening met de specifieke kenmerken van moderne controllers en lees ik aanvullend de Handleiding voor cgroup v2, om waarden consistent te interpreteren en verkeerde inschattingen te voorkomen, wat de Nauwkeurigheid toegenomen.
CLI-workflow voor gevorderden: lvectl, cloudlinux-limits, cloudlinux-config
Ik maak gebruik van automatisering voor massale wijzigingen en pas lvectl rechtstreeks toe op UID’s als de gebruikersinterface me te traag lijkt, waardoor ik mijn Routine verhogen. Voorbeeld: „lvectl set 504 –speed=150%“ verhoogt de CPU van één account. Met „lvectl set 504 –speed=100% –pmem=1G –io=2048“ stel ik CPU, RAM en IO in één stap in. Als ik limieten moet verwijderen, helpt „lvectl set 504 –unlimited“. Voor algemene instellingen gebruik ik „cloudlinux-limits“ en voor UI- en meldingsdetails „cloudlinux-config“. Vooral bij de uitrol van nieuwe pakketten of bij het op elkaar afstemmen van reseller-omgevingen bespaart deze aanpak me veel tijd en vermindert het het aantal typefouten, waardoor ik de kwaliteit verhoog.
# Voorbeelden
lvectl set 504 --speed=150%
lvectl set 504 --speed=100% --pmem=1G --io=2048
lvectl set 504 --unlimited
De veiligheid verhogen: consequent gebruikmaken van CageFS en procesisolatie
Ik schakel CageFS in voor alle accounts met shell- of SFTP-toegang, zodat elke klant in een eigen bestandssysteemkooi werkt en geen gevoelige paden te zien krijgt, wat de Afscherming verbeterd. Daarbij houd ik de omgeving gestroomlijnd en geef ik alleen de noodzakelijke tools vrij om het aanvalsoppervlak zo klein mogelijk te houden. PHP-versies en extensies wijs ik per account zorgvuldig toe en documenteer ik deze beslissingen, met name bij opstellingen met meerdere domeinen. LVE-limieten en CageFS vullen elkaar aan: de limieten beperken de beschikbare resources, terwijl de isolatie laterale bewegingen binnen het systeem voorkomt. Deze combinatie beperkt de schade bij incidenten en maakt uitschieters beheersbaar, zodat ik incidenten sneller kan inperken en de Restauratie versnel.
I/O- en CPU-bottlenecks doelgericht verhelpen
Ik ga na of limieten of applicaties de bottleneck vormen, voordat ik de cijfers aanpas, zodat ik de oorzaken in plaats van de symptomen aanpak en de Efficiëntie veiliger. Bij veel kleine bestanden verhoog ik eerder de IOPS, bij grote overdrachten eerder de IO in MB/s; op NVMe kan ik beide ruimschoots toewijzen dan op SATA. Als er bij verkeerspieken 503-meldingen optreden, breid ik eerst EP uit en, indien nodig, NPROC. CPU-fouten als gevolg van inefficiënte plug-ins los ik vaak sneller op met caching en versie-updates dan met herhaalde SPEED-verhogingen. Na elke wijziging bekijk ik de statistieken opnieuw om te controleren of de aanpassing effect heeft en of ik op andere punten nog iets moet bijstellen, zodat de Totale belasting in evenwicht blijft.
Checklist voor de praktijk en het vermijden van veelgemaakte fouten
Ik schakel VMEM consequent uit, omdat virtuele geheugenlimieten tot verkeerde interpretaties kunnen leiden, en laat PMEM als enige geheugenlimiet actief, wat de Planbaarheid verhoogd. Ik stel EP niet te laag in, omdat te weinig entry-processen direct tot 503-responsen leiden; liever wat ruimte laten en later nauwkeuriger afstemmen. IO/IOPS pas ik aan de opslagklasse aan en controleer ik of back-ups, cronjobs of zoekindexen piekbelastingen veroorzaken. Bij database-hotspots zet ik aanvullend in op de MySQL Governor, om het aantal query’s binnen de perken te houden en de weblimieten te ontlasten. En ik documenteer elke wijziging met datum en motivering, zodat ik de ontwikkelingen kan volgen en indien nodig een terugdraaiing kan uitvoeren, wat de Transparantie beveiligt.
Hoe limieten op elkaar inwerken en veelvoorkomende misvattingen
Ik beschouw de limieten als op elkaar inwerkende regelaars en stel ze zo in dat ze elkaar niet blokkeren: SPEED is de CPU-quota per account; 100 % komt in de praktijk overeen met ongeveer één volledige CPU-kern, 200 % met twee kernen, enzovoort. PMEM beperkt de daadwerkelijk gebruikte fysieke opslagruimte van een account en treedt onmiddellijk in werking, terwijl VMEM (uitgeschakeld) leidde vaak tot misleidende 'out-of-memory'-meldingen. EP registreert gelijktijdige inkomende webverzoeken (bijv. PHP-verzoeken) en is vaak de eerste oorzaak van 503-fouten wanneer deze waarde te laag is ingesteld. NPROC telt processen en threads bij elkaar op; ik houd daar rekening mee bij workers die intern threads aanmaken. IO beperkt de overdrachtssnelheid in MB/s, IOPS het aantal bewerkingen per seconde; kleine bestanden hebben invloed op de IOPS, grote bestanden op de IO. Ik zorg ervoor dat de IO en de IOPS op elkaar zijn afgestemd, zodat ik niet te vroeg tegen het plafond aanloop.
PHP-handlers, caching en de dimensionering van EP/NPROC
Ik stem EP en NPROC af op het daadwerkelijke uitvoeringsmodel van de webapps. Als ik PHP-FPM gebruik, baseer ik EP op pm.max_children plus een buffer: als vuistregel stel ik EP in op ≈ 1,2–1,5 × pm.max_children, zodat korte pieken en handshakes niet meteen een 503-fout veroorzaken. Ik kies een ruimere waarde voor NPROC (vaak 2–3 × EP), omdat cron-taken, onderhoudstaken en shell-commando’s extra processen verbruiken. Als ik met mod_lsapi of LiteSpeed/LSAPI werk, houd ik er rekening mee dat Keep-Alive en interne workers tijdelijk tot hogere EP-waarden leiden; daarom bouw ik extra ruimte in. Ik kies altijd voor OPcache en een objectcache, omdat deze CPU-tijd besparen en het aantal parallel draaiende PHP-processen verminderen. Caching is mijn voorkeursmaatregel voordat ik SPEED of EP permanent verhoog.
Startwaarden nog nauwkeuriger: profielen per toepassingstype
Ik stem de standaardinstellingen af op de werklast: een contentblog met veel statische bestanden heeft meer baat bij hogere IO/IOPS en gematigde EP, terwijl een webshop (bijvoorbeeld met zwaardere plug-ins en winkelwagenlogica) eerder hogere EP/SPEED en PMEM nodig heeft. Voor sites die veel gebruikmaken van page builders (page builders, veel shortcodes) plan ik bovendien extra PMEM in, zodat redacteuren niet tegen de limiet aanlopen. Headless- of API-gebruik schaal ik via EP en SPEED, omdat daar veel korte, parallelle verzoeken plaatsvinden. Bij een sterke focus op media (galerijen, downloads) geef ik meer gewicht aan IO en zorg ik voor voldoende IOPS, zodat thumbnails en metadata vlot worden verwerkt. Deze profilering houdt de Prestaties stabiel per use case, zonder middelen te verspillen.
De bijzonderheden van cgroup v2 correct interpreteren
Ik houd rekening met de manier waarop controllers onder cgroup v2 worden weergegeven: SPEED wordt geïmplementeerd als quota/max, waardoor er korte pieken in de statistieken kunnen optreden, hoewel de gebruikerservaring stabiel blijft. Ik maak consequent onderscheid tussen „gebruik“ (bijv. CPU-tijd) en „fouten“ (harde limietoverschrijdingen). Als ik sporadische CPU-pieken zie zonder fouten, laat ik de limieten vaak ongewijzigd en blijf ik de situatie observeren. Als er series van fouten optreden op vergelijkbare tijdstippen van de dag, pas ik de limieten nauwkeurig aan. Voor een nauwkeurige interpretatie gebruik ik de eerder genoemde Handleiding voor cgroup v2 en vergelijk de UI-waarden met de CLI-uitvoer, zodat ik geen schijnproblemen ga opsporen.
Back-up-, index- en cron-vensters inplannen
Ik spreid voorspelbare belasting: back-ups, indexeringsprocessen, het opstellen van sitemaps en het opnieuw indexeren van zoekresultaten plan ik in buiten de piekuren en stem ik af met resellers. Indien nodig verlaag ik tijdelijk de IO/IOPS voor afzonderlijke accounts om de dagelijkse activiteiten te beschermen, of verhoog ik deze „s nachts wanneer er grote kopieertaken op het programma staan. Bij rekenintensieve cron-taken beperk ik de mate van parallelliteit en maak ik slim gebruik van “nice/ionice“, zodat deze processen niet ten koste gaan van SPEED/IO. Al met al houd ik het platform zo stabiel, zonder de voortgang van onderhoudstaken te vertragen.
Handleiding voor probleemoplossing: van storing tot maatregel
Ik werk systematisch: 1) Het type fout identificeren (SPEED, PMEM, IO, IOPS, EP, NPROC). 2) De periode, de frequentie en de omvang van de storing vaststellen. 3) De logbestanden van de applicatie en de webserver controleren. 4) Een maatregel kiezen. Bij SPEED-fouten controleer ik caching, plug-ins en query’s en verhoog ik de snelheid slechts in beperkte mate, als dat echt nodig is. Bij PMEM-fouten analyseer ik het aantal workers (bijv. pm.max_children) en de geheugenpieken van afzonderlijke plug-ins; in plaats van PMEM klakkeloos te verhogen, verminder ik vaak eerst de parallelle uitvoering. Bij IO/IOPS-storingen Ik maak onderscheid tussen veel kleine bestandsbewerkingen en grote overdrachten en pas de juiste regelaar heel nauwkeurig aan. EP-fouten los ik op door meer EP en/of kortere verzoektijden (caching, beeldcompressie), terwijl ik bij NPROC-fouten Ik elimineer runaway-processen (foutieve cronjobs, loops). Na elke wijziging voer ik opnieuw een meting uit om te controleren of de maatregel effect heeft.
Risicovrije implementatie en wijzigingsbeheer
Ik voer nieuwe standaardinstellingen stapsgewijs in: eerst test ik ze met een klein aantal representatieve accounts (Canary-groep), daarna breid ik dit uit naar een heel pakketniveau. Vooraf sla ik de bestaande waarden op en leg ik een duidelijk terugdraaiscenario vast voor het geval er afwijkingen optreden. Grotere aanpassingen communiceer ik tijdig aan resellers en betrokken klanten („venster“, verwachte effecten, zelfcontrole in „Resource Usage“). Na de uitrol houd ik de storingspercentages en helpdesktickets in de gaten; als deze binnen de norm blijven, neem ik de waarden over als nieuwe Standaard. Deze discipline voorkomt verrassingen en zorgt ervoor dat het vertrouwen hoog blijft.
Beheer van wederverkopers en eerlijke verdeling
Ik stel duidelijke bovengrenzen vast voor resellers en leg het verdelingsmechanisme uit, zodat ze de limieten op een zinvolle manier over subaccounts kunnen verdelen. Voor seizoenscampagnes wijs ik tijdelijke budgetten toe, maar ik vraag wel om een korte rapportage achteraf (welke sites? welke looptijd? welke pieken?). Ik controleer regelmatig uitschieters binnen een resellerpool en bied opwaarderingen aan voordat strenge limieten van kracht worden. Zo houd ik me aan het fair-use-beleid zonder de groei te remmen en minimaliseer ik escalaties, omdat de criteria en de werkwijze transparant zijn.
Fijnafstemming op basis van de databasebelasting en de webstack
Ik breng Web-Faults in verband met databasestatistieken: als ik veel CPU-tijd in de PHP-laag zie in combinatie met trage query’s, ontlast ik de stack door middel van caching, indexen en, waar zinvol, de MySQL Governor. Aan de webserverzijde controleer ik of Keep-Alive-instellingen of ongunstige time-outwaarden de EP kunstmatig hoog houden. Voor het verwerken van afbeeldingen en assets schakel ik compressie en HTTP/2-multiplexing in en zorg ik ervoor dat statische inhoud agressief in de cache wordt opgeslagen. Deze holistische benadering voorkomt dat ik limieten verhoog op plaatsen waar eigenlijk de app of de database-laag moet worden geoptimaliseerd.
Vergeet het onderhoud van de kernel en de componenten niet
Ik houd de kernel, LVE-pakketten en de PHP-stack up-to-date en plan daarvoor korte onderhoudsvensters in. Na updates controleer ik of de LVE-statistieken nog steeds worden bijgewerkt en of het gedrag van controllers (vooral onder cgroup v2) nog steeds op dezelfde manier wordt geïnterpreteerd. Waar nodig start ik diensten gericht opnieuw op, in plaats van de gehele host te rebooten, en documenteer ik wijzigingen aan het basissysteem apart van pakket- en gebruikersaanpassingen. Zo voorkom ik dat prestatieverschillen ten onrechte aan de LVE-waarden worden toegeschreven.
Belastingstests en capaciteitsplanning
Ik voer regelmatig gematigde belastingstests uit die het daadwerkelijke gebruik simuleren (burst-verkeer, cache-miss-scenario’s, checkout-processen). Daarbij kijk ik bij welk limiet zich als eerste fouten voordoen en verzamel ik basiswaarden per tariefniveau. Deze waarden helpen mij om verkooppakketten betrouwbaar te beschrijven en op feiten gebaseerde upgrade-aanbevelingen te doen. Voor hosts met heterogene hardware (SATA versus NVMe) houd ik per klasse aparte standaardsjablonen bij, zodat de Prestaties per knooppunt consistent werkt.
Samenvatting: Zo zet ik de LVE Manager winstgevend in
Ik begin met schone standaardpakketten, schakel VMEM uit, stel redelijke CPU- en RAM-limieten in en schaal IO/IOPS op basis van de opslagklasse, zodat ik voorspelbare Prestaties ontvang. Vervolgens koppel ik LVE-pakketten aan de panelpakketten, zodat elk nieuw account meteen de juiste limieten krijgt. Individuele afwijkingen ken ik alleen gericht en voor een beperkte tijd toe, met name voor campagnes of seizoenspieken. Monitoring is geen bijzaak: ik analyseer fouten regelmatig, pas limieten zorgvuldig aan en betrek klanten bij hun eigen gebruik. Met CageFS en optionele tools zoals CLI en Governor houd ik het platform veilig, eerlijk en responsief, terwijl ik tegelijkertijd de ondersteuningskosten verlaag en de Klantervaring verbeteren.
