Wat betreft het afstellen van de CloudLinux limieten zijn er wel richtlijnen maar geen vaste formules. Het fine-tunen lukt vaak niet in één keer - je zult het soms een paar keer opnieuw moeten bekijken en aanpassen voordat het goed ingesteld staat.

Wat je wil doen is een balans vinden tussen wat de gebruiker nodig heeft om de applicaties die erop staan goed te laten draaien, en wat de server maximaal kan missen aan resources. Als die balans niet gevonden kan worden betekent dat:

1. dat je moet kijken of je misschien een webapplicatie onder een gebruiker hebt draaien die meer resources verbruikt dan eigenlijk normaal is, en dan zou je kunnen kijken wat er fout gaat en of je het resourceverbruik kunt inperken
2. of - als je alles al zoveel mogelijk getuned hebt en toch nog steeds tekort komt - dan betekent dat dat je de server zult moeten upgraden

Na het installeren van CloudLinux kan het geen kwaad om even een uurtje te wachten met limieten instellen totdat er wat informatie verzameld is over het resourceverbuik van iedere user. Aan de hand van de CloudLinux History grafieken kun je dan proberen in te schatten hoe hoog de limieten zouden moeten zijn.

Hoe weet je welke waardes je moet geven?

Hier zijn wat handreikingen en voorbeelden die je daarbij kunt gebruiken:

SPEED limiet:

Bij het instellen van een initiële SPEED limiet kun je er het beste voor zorgen dat gebruikers nooit in hun eentje of met zijn tweeën de hele voorraad CPU op kunnen verbruiken. Stel dat de server 8 cores heeft dan zouden twee gebruikers met een SPEED limiet van 400% samen de server omver kunnen trekken. Dan kun je die gebruikers dus beter niet meer dan 300% SPEED limiet geven. Veel websites zullen voldoende hebben aan 200% tot 400%.

PMEM limiet:

Voor de meeste kleine tot middelgrote websites zal 2GB tot 3GB al wel voldoende zijn. Maar hierbij is het goed om eerst even te kijken hoeveel geheugen er voor MySQL gereserveerd is. Als je dat aftrekt van de totale hoeveelheid RAM op de server dan heb je een beetje een indicatie van wat er nog te verdelen valt. Stel bijvoorbeeld dat je server 24GB RAM heeft, en MySQL heeft 5GB gereserveerd dan blijft er nog 19GB RAM over voor de rest. De exacte limiet die je dan in zou moeten stellen hangt uiteraard af van de hoeveelheid gebruikers en hun maximale verbruik, maar ik raad je aan om dan niet meer dan een derde daarvan - in dit voorbeeld ≤ 6,5GB - per gebruiker toe te kennen.

VMEM limiet:

De VMEM mag je helemaal negeren, dit is een waarde waarvan de developers van CloudLinux hebben aangegeven dat die niet meer gebruikt zou moeten worden (Zie ook: https://docs.cloudlinux.com/shared/limits/)

EP limiet:

De meeste applicaties zullen aan 20 tot 60 entry processes wel voldoende hebben. Maar als de server voldoende CPU en RAM heeft kun je soms wel tot 150 gaan voor high-end pakketten.

NPROC limiet:

Hou deze limiet altijd iets hoger dan de EP limiet. Voorbeeld: is de EP limiet 40? Geeft de NPROC dan bijvoorbeeld een limiet van 50

I/O limiet:

Dit is de maximum snelheid waarmee een gebruiker kan lezen of schrijven naar disk. Voor de meeste gebruikers zal 12MB/s à 16MB/s wel voldoende zijn, maar het is meestal niet zo erg als je deze wat hoger instelt. Te laag instellen zal ervoor zorgen dat eindgebruikers / bezoekers vertraging merken.

IOPS limiet:

Hiermee stel je het aantal keren per seconde in waarmee je kunt schrijven of lezen op de disk. IOPS staat vaak in eerste instantie op 1024, en meestal is dat ruim voldoende, maar als een user tegen deze limiet aanloopt kun je hem vaak zonder problemen een limiet van 2048 geven.

Let op dat de I/O en IOPS limieten samen verantwoordelijk zijn voor de zogenaamde ‘throughput’ op de disk. Als je ze bij een intensieve gebruiker allebei tegelijk erg hoog instelt dan kan dat er in bepaalde gevallen voor zorgen dat de DISK I/O op de server allemaal door die gebruiker in beslag wordt genomen. Al het andere op de server zal dan traag tot zeer traag reageren.