Passer au contenu 
Ich zeige dir, wie du den CloudLinux LVE Manager im Shared Hosting korrekt konfigurierst und die wichtigsten cloudlinux lve Limits sinnvoll setzt. So steuerst du CPU, RAM, I/O und Prozesse pro Account gezielt, vermeidest Engpässe und hältst Nachbarn von Ausreißern fern.
Points centraux
Bevor ich in die Details gehe, fasse ich die wichtigsten Entscheidungen zusammen, die über eine konstante Hosting-Qualität entscheiden.
- VMEM aus: Speicher nur über PMEM limitieren
- CPU realistisch: mindestens 100 %, häufig 200 %
- IO/IOPS: Werte an Storage (SATA/SSD/NVMe) ausrichten
- EP/NPROC: genug Spielraum gegen 503-Fehler
- Suivi: Faults beobachten, Limits nachregeln
LVE Manager kurz einrichten: Zugang und Grundkonfiguration
Ich melde mich in WHM als root an und öffne den Eintrag „CloudLinux Manager“ oder „CloudLinux LVE Manager“, je nach Panel-Version, um die Surface freizuschalten. Fehlt der Eintrag, installiere ich das Paket lvemanager oder lasse bei Neuaufsetzungen das Skript cldeploy laufen, das Kernel, LVE-Komponenten und lvestats aktiviert. Anschließend prüfe ich, ob Statistiken schreiben und ob neue Konten automatisch die Standardlimits erhalten. In Plesk oder DirectAdmin gehe ich analog vor, denn die UI-Elemente und Funktionen sind sehr ähnlich. Erst wenn der Manager sichtbar, die Dienste aktiv und die LVE-Statistiken gefüllt sind, beginne ich mit der eigentlichen Limit-Planung und Dokumentation der Défauts.
Die Limits richtig wählen: SPEED, PMEM, IO, IOPS, EP, NPROC
Ich starte mit SPEED, weil CPU-Drosselungen Websites direkt ausbremsen, und setze mindestens 100 %, meist 200 % für gängige CMS, damit Lastspitzen nicht sofort greifen und die Performance konstant bleibt. PMEM definiere ich als maßgebliches Speicherlimit und deaktiviere VMEM komplett, da virtueller Speicher ungenau wirkt und Fehlalarme provoziert. IO lege ich in MB/s fest und passe den Wert dem Storage an: auf SATA eher konservativ, auf NVMe großzügiger. IOPS begrenze ich gegen sehr viele kleine Zugriffe, was auf dynamischen Seiten mit vielen Dateien wichtig ist. EP halte ich so hoch, dass bei kurzzeitigen Spitzen keine 503-Fehler auftreten, und NPROC schützt vor zu vielen Prozessen durch Cronjobs oder fehlerhafte Skripte, sodass die Charge du serveur planbar bleibt. Für eine praxisnahe Einordnung hilft mir dieser kompakte Leitfaden zu LVE‑Limits einrichten.
Startwerte und bewährte Defaults für Shared Hosting
Ich deaktiviere VMEM grundsätzlich und steuere Speicher nur über PMEM, da ich damit planbarere Effekte erziele und Fehlermeldungen meide, die bei Auslagerung entstehen könnten; dieser Schritt bildet die Basis für kalkulierbares Ressourcen-Management. Als Startwerte setze ich meist 100–200 % CPU, 1–2 GB PMEM, 5–10 MB/s IO, 1024–4096 IOPS, 20–40 EP und 100–200 NPROC, wobei Premium-Pakete höhere I/O- und CPU-Budgets erhalten. Auf besonders schnellen NVMe-Systemen erhöhe ich IO/IOPS, ohne andere Kunden zu beeinträchtigen, sofern das Gesamtsystem ausreichend Reserven aufweist. Diese Startwerte betrachte ich nicht als endgültig, sondern als Ausgangspunkt für Messung, Auswertung und Nachregelung. Ich bewerte Faults, saisonale Muster und Workloads je nach Anwendungstyp und schiebe Grenzwerte graduell, bis sie zu den realen Profilen passen, womit ich Throttling Ereignisse planvoll reduziere.
| Tariftyp | CPU (SPEED) | PMEM | IO | IOPS | EP | NPROC |
|---|---|---|---|---|---|---|
| Basis (Blog/Portfolio) | 100 % | 1 GB | 5 MB/s | 1024 | 20 | 100 |
| Business (KMU‑Site) | 200 % | 2 GO | 10 MB/s | 4096 | 30 | 150 |
| E‑Commerce (Shop) | 300 % | 4 GO | 20 MB/s | 8192 | 40 | 200 |
| Agentur/Reseller (pro Kunde) | 200 % | 2 GO | 15 MB/s | 6144 | 40 | 200 |
Pakete im LVE Manager aufbauen und mit Panel-Paketen koppeln
Ich strukturiere zuerst LVE‑Pakete nach Kundentypen, damit Limits pro Stufe konsistent greifen und ich Upgrades ohne manuelles Nachziehen umsetzen kann; das erleichtert meinen Soutien spürbar. In der Packages-Ansicht lege ich Basis-, Business- und E‑Commerce‑Profile mit den oben genannten Werten an. In WHM öffne ich dann „Edit a Package“, scrolle zu „CloudLinux LVE Settings“ und binde je cPanel‑Paket das passende LVE‑Profil ein, sodass Neu- und Bestandskonten automatisch die Limits übernehmen. Diese Kopplung ist entscheidend, damit Sales‑Pakete und Technik nicht auseinanderlaufen und Kunden nachvollziehbare Ressourcen erhalten. Wenn Kunden besondere Anforderungen haben, skaliere ich über ein höheres Paket oder passe zeitweise pro Account an, ohne die Tariflogik zu verlassen, was die Consistance bewahrt.
Individuelle Anpassungen und Reseller-Limits setzen
Ich öffne die Users-Ansicht im LVE Manager, wähle den Zielaccount und editiere SPEED, PMEM, IO, IOPS, EP und NPROC direkt, wenn ein Projekt kurzfristig mehr Budget benötigt; so löse ich Lastspitzen, ohne die gesamte Plattform zu verändern, was die Flexibilité erhöht. Für Reseller aktiviere ich „Manage Limits“ auf dem Reseller‑Account und vergebe ein eigenes Kontingent, das der Wiederverkäufer auf seine Kunden verteilt. Damit bleibt der Reseller in seinem Rahmen, während ich als Administrator die Obergrenze sichere. Bei Promotions oder saisonalen Peaks (z. B. Feiertage) plane ich temporäre Anhebungen vor und setze danach die Ausgangswerte zurück. Diese Vorgehensweise schafft Transparenz und verhindert Diskussionen über diffuses „Langsamsein“, weil ich Zahlen, Faults und Zeiträume klar benennen kann, was die Traçabilité renforce.
Überwachen, auswerten, nachregeln: LVE-Statistiken richtig lesen
Ich schaue mir in der LVE-Statistik pro Benutzer die Nutzung und die Fault‑Events an und achte besonders auf wiederkehrende CPU‑, Memory‑ oder I/O‑Spitzen, weil sie auf Konfigurationsbedarf hindeuten und die Capacité beeinflussen. In cPanel verweise ich Kunden auf „Resource Usage“, damit sie ihre eigene Lage sehen und Plugins oder Jobs selbst optimieren können. Bevor ich harte Deckel setze, sammle ich einige Tage Messwerte, um Rauschen von Mustern zu trennen. Danach ziehe ich Limits in kleinen Schritten hoch oder runter und prüfe die Effekte erneut. Arbeite ich auf neueren Distributionen mit einem anderen Controller-Layout, berücksichtige ich die Besonderheiten von modernen Controllern und lese ergänzend den cgroup v2 Leitfaden, um Werte konsistent zu interpretieren und Fehleinschätzungen zu vermeiden, was die Précision du tir augmente.
CLI-Workflow für Fortgeschrittene: lvectl, cloudlinux-limits, cloudlinux-config
Ich setze Automatisierung für Massenänderungen ein und nutze lvectl direkt auf UIDs, wenn mir die UI zu langsam ist, wodurch ich meine Routine limite. Exemple : „ lvectl set 504 –speed=150% “ augmente la puissance de calcul d'un compte individuel. Avec „ lvectl set 504 –speed=100% –pmem=1G –io=2048 “, je configure le CPU, la RAM et les E/S en une seule étape. Si je dois supprimer des limites, la commande „ lvectl set 504 –unlimited “ m'aide. Pour les paramètres globaux, j’utilise „ cloudlinux-limits “ et pour les détails relatifs à l’interface utilisateur et aux notifications, „ cloudlinux-config “. Cette approche me fait gagner beaucoup de temps, notamment lors du déploiement de nouveaux paquets ou de l’harmonisation d’environnements de revendeurs, et réduit les fautes de frappe, ce qui me permet de Qualité augmenter.
Exemples #
lvectl set 504 --speed=150%
lvectl set 504 --speed=100% --pmem=1G --io=2048
lvectl set 504 --unlimited
Renforcer la sécurité : exploiter pleinement CageFS et l'isolation des processus
J'active CageFS pour tous les comptes disposant d'un accès shell ou SFTP, afin que chaque client travaille dans sa propre cage de système de fichiers et ne puisse pas voir les chemins d'accès sensibles, ce qui isolement amélioré. Je veille à ce que l’environnement reste allégé et je n’autorise que les outils indispensables afin de réduire au minimum la surface d’attaque. J’attribue clairement les versions PHP et les extensions à chaque compte et je documente ces choix, en particulier dans le cas de configurations multi-domaines. Les limites LVE et CageFS se complètent : les limites plafonnent les ressources, tandis que l’isolation empêche les mouvements latéraux dans le système. Cette combinaison limite les dégâts en cas d’incident et rend les écarts contrôlables, ce qui me permet de circonscrire plus rapidement les incidents et de Restauration accélère.
Réduire de manière ciblée les goulots d'étranglement au niveau des E/S et du processeur
Je vérifie si ce sont les limites ou les applications qui constituent le goulot d'étranglement avant de modifier les chiffres, afin de m'attaquer aux causes plutôt qu'aux symptômes et de Efficacité sûre. Avec de nombreux petits fichiers, je privilégie l’augmentation des IOPS, tandis que pour les transferts volumineux, je privilégie le débit en Mo/s ; sur NVMe, je peux allouer davantage de ressources aux deux que sur SATA. Si des messages 503 apparaissent lors des pics de trafic, j’augmente d’abord l’EP et, si nécessaire, le NPROC. Je résous souvent plus rapidement les erreurs CPU causées par des plugins inefficaces en recourant à la mise en cache et aux mises à jour de version plutôt qu’en augmentant à plusieurs reprises la valeur SPEED. Après chaque modification, je réexamine les statistiques pour vérifier si l’ajustement est efficace et s’il faut intervenir à d’autres niveaux afin que la Charge totale reste équilibré.
Liste de contrôle pratique et comment éviter les erreurs courantes
Je désactive systématiquement VMEM, car les limites de mémoire virtuelle peuvent prêter à confusion, et je ne laisse activée que la limite de mémoire PMEM, ce qui permet de Planification augmenté. Je ne règle pas l'EP trop bas, car un nombre insuffisant de processus d'entrée entraîne immédiatement des réponses 503 ; je préfère laisser une marge de manœuvre et affiner le réglage par la suite. J'adapte les valeurs IO/IOPS à la classe de stockage et je vérifie si les sauvegardes, les tâches Cron ou les index de recherche génèrent des pics de charge. En cas de points chauds dans la base de données, je mise en complément sur le MySQL Governor, afin de limiter le nombre de requêtes et d'alléger la charge sur les limites du site. Et je consigne chaque modification en précisant la date et la raison, afin de pouvoir retracer l'évolution et, si nécessaire, revenir en arrière, ce qui Transparence sécurisé.
Comment les limites interagissent et les malentendus courants
Je considère les limites comme des régulateurs qui interagissent et je les règle de manière à ce qu'ils ne se bloquent pas mutuellement : SPEED Il s'agit du quota CPU par compte ; dans la pratique, 100 % correspondent à environ un cœur de processeur complet, 200 % à deux cœurs, etc. PMEM limite la mémoire physique réellement occupée par un compte et prend effet immédiatement, tandis que VMEM (désactivé) entraînait souvent des messages d'erreur « Out of Memory » trompeurs. EP Il enregistre les accès Web simultanés entrants (par exemple, les requêtes PHP) et constitue souvent le premier facteur déclencheur des erreurs 503 lorsqu'il est défini à une valeur trop faible. NPROC compte le nombre total de processus et de threads ; j'en tiens compte pour les workers qui créent des threads en interne. IO limite le débit de transfert en Mo/s, IOPS le nombre d'opérations par seconde ; les petits fichiers ont un impact sur les IOPS, tandis que les gros fichiers ont un impact sur les IO. Je m'assure que les IO et les IOPS sont adaptés les uns aux autres, afin de ne pas atteindre la limite avant d'avoir épuisé toutes les autres possibilités.
Handlers PHP, mise en cache et dimensionnement d'EP/NPROC
J'ajuste les valeurs EP et NPROC en fonction du modèle d'exécution réel des applications web. Si j’utilise PHP-FPM, je base EP sur la valeur de pm.max_children plus une marge : en règle générale, je définis EP ≈ 1,2–1,5 × pm.max_children, afin que les pics de trafic courts et les handshakes ne génèrent pas immédiatement des erreurs 503. Je choisis une valeur plus généreuse pour NPROC (souvent 2 à 3 × EP), car les tâches cron, les opérations de maintenance et les commandes shell consomment des processus supplémentaires. Si j’utilise mod_lsapi ou LiteSpeed/LSAPI, je tiens compte du fait que le Keep-Alive et les workers internes entraînent des pics temporaires de la valeur EP ; je prévois donc une marge supplémentaire en conséquence. Je mise toujours sur OPcache et un cache d'objets, car ils permettent de gagner du temps CPU et de réduire le nombre de processus PHP s'exécutant en parallèle. La mise en cache est la première solution que je privilégie avant d'augmenter de manière permanente les paramètres SPEED ou EP.
Des valeurs de départ encore plus précises : profils par type d'application
Je différencie les paramètres par défaut en fonction de la charge de travail : un blog de contenu comportant de nombreux éléments statiques tire davantage parti d’un IO/IOPS plus élevé et d’un EP modéré, tandis qu’une boutique en ligne (avec, par exemple, des plugins plus lourds et une logique de panier) a plutôt besoin d’un EP/SPEED et d’un PMEM plus élevés. Pour les sites faisant un usage intensif de constructeurs de pages (Page Builder, nombreux shortcodes), je prévois en outre davantage de PMEM afin que les éditeurs n’atteignent pas la limite. Pour l’utilisation en mode headless ou via API, je scale via l’EP et le SPEED, car ces scénarios génèrent de nombreuses requêtes courtes et parallèles. En cas de forte présence de médias (galeries, téléchargements), je privilégie davantage l’IO et je veille à disposer d’un nombre suffisant d’IOPS pour que les vignettes et les métadonnées soient traitées rapidement. Ce profil permet de maintenir la Performance stable pour chaque cas d'utilisation, sans gaspiller de ressources.
Bien comprendre les particularités de cgroup v2
Je tiens compte de la manière dont les contrôleurs sont mappés sous cgroup v2 : SPEED est implémenté sous forme de quota/limite maximale, ce qui peut entraîner de brefs pics dans les métriques, même si l'expérience utilisateur reste stable. Je fais systématiquement la distinction entre „ utilisation “ (par exemple, le temps CPU) et les „ faults “ (dépassements de limites strictes). Si j’observe des pics sporadiques de CPU sans faults, je laisse souvent les limites inchangées et je continue à surveiller la situation. Si les « Faults » se produisent en série et à des heures similaires de la journée, j’effectue des ajustements précis. Pour une analyse détaillée, j’utilise l’outil déjà mentionné cgroup v2 Leitfaden et je compare les valeurs de l'interface utilisateur avec celles affichées par la ligne de commande, pour m'assurer de ne pas me tromper sur la nature du problème.
Rendre les fenêtres de sauvegarde, d'indexation et de Cron programmables
Je répartis les charges prévisibles : je programme les sauvegardes, les indexations, la création des plans de site et la réindexation des recherches pendant les heures creuses et je les coordonne avec les revendeurs. Si nécessaire, je réduis temporairement les valeurs IO/IOPS pour certains comptes afin de protéger l’activité quotidienne, ou je les augmente la nuit lorsque des tâches de copie volumineuses sont prévues. Pour les tâches cron gourmandes en ressources de calcul, je limite leur exécution en parallèle et j’utilise judicieusement les paramètres „ nice/ionice “ afin que ces processus n’entrent pas en concurrence avec les ressources SPEED/IO. Au final, je parviens ainsi à maintenir la stabilité de la plateforme sans entraver la progression des tâches de maintenance.
Guide de dépannage : de la panne à la mesure corrective
Je procède de manière systématique : 1) Identifier le type de défaillance (SPEED, PMEM, IO, IOPS, EP, NPROC). 2) Déterminer la période, la fréquence et l'ampleur du problème. 3) Vérifier les journaux de l'application et du serveur web. 4) Choisir une mesure corrective. Dans le cas de Défauts SPEED je vérifie la mise en cache, les plugins et les requêtes, et je n'augmente la VITESSE que modérément, si cela s'avère vraiment nécessaire. Dans le cas de Défauts PMEM j'analyse le nombre de workers (par exemple pm.max_children) et les pics de mémoire de chaque plugin ; au lieu d'augmenter PMEM à l'aveuglette, je commence souvent par réduire l'exécution parallèle. Dans le cas de Erreurs d'E/S et d'IOPS Je fais la distinction entre les nombreuses petites opérations sur les fichiers et les transferts volumineux, et j'ajuste le paramètre approprié avec précision. Défauts EP je résous ce problème en augmentant l'EP et/ou en réduisant les temps de requête (mise en cache, compression d'images), tandis que dans le cas de NPROC‑Faults J'élimine les processus incontrôlés (tâches Cron défectueuses, boucles). Après chaque modification, je procède à une nouvelle mesure pour vérifier que la mesure prise est efficace.
Gestion du déploiement et des modifications sans risque
Ich führe neue Defaults in Stufen ein: Zuerst teste ich mit wenigen repräsentativen Konten (Canary‑Gruppe), danach skaliere ich auf eine ganze Paketstufe. Vorher sichere ich die bestehenden Werte und notiere ein klares Rückroll‑Szenario, falls Anomalien auftreten. Größere Anpassungen kommuniziere ich frühzeitig an Reseller und betroffene Kunden („Fenster“, erwartete Effekte, Self‑Check in „Resource Usage“). Nach dem Rollout beobachte ich Fault‑Raten und Helpdesk‑Tickets; bleiben sie unauffällig, übernehme ich die Werte als neue Défauts. Diese Disziplin verhindert Überraschungen und hält das Vertrauen hoch.
Reseller‑Governance und faire Verteilung
Ich setze für Reseller klare Obergrenzen und erkläre die Verteilmechanik, damit sie Limits sinnvoll auf Unterkonten staffeln. Für saisonale Kampagnen räume ich zeitlich befristete Budgets ein, verlange aber eine kurze Nachdokumentation (Welche Sites? Welche Laufzeit? Welche Peaks?). Ich prüfe regelmäßig Ausreißer innerhalb eines Reseller‑Pools und biete Aufstufungen an, bevor harte Caps greifen. So halte ich Fair‑Use ein, ohne Wachstum zu bremsen, und minimiere Eskalationen, weil Kriterien und Vorgehen transparent sind.
Feinabstimmung mit Datenbank‑Last und Webstack
Ich korreliere Web‑Faults mit Datenbank‑Metriken: Siehe ich hohe CPU‑Zeit im PHP‑Layer bei gleichzeitig langsamen Queries, entlaste ich den Stack über Caching, Indexe und, wo sinnvoll, den MySQL Governor. Auf Webserver‑Seite prüfe ich, ob Keep‑Alive‑Settings oder ungünstige Timeout‑Werte EP künstlich hochhalten. Für Bild‑/Asset‑Handling aktiviere ich Kompression, HTTP/2‑Multiplexing und stelle sicher, dass statische Inhalte aggressiv gecacht werden. Diese ganzheitliche Sicht verhindert, dass ich Limits dort erhöhe, wo eigentlich die App oder der DB‑Layer optimiert werden muss.
Kernel‑ und Komponentenpflege nicht vernachlässigen
Ich halte Kernel, LVE‑Pakete und den PHP‑Stack aktuell und plane dazu kurze Wartungsfenster. Nach Updates kontrolliere ich, ob die LVE‑Statistiken weiterhin schreiben und ob Controller‑Verhalten (v. a. unter cgroup v2) unverändert interpretiert wird. Wo nötig, starte ich Dienste gezielt neu, anstatt den gesamten Host zu rebooten, und dokumentiere Änderungen am Basissystem separat von Paket‑/User‑Anpassungen. So verhindere ich, dass Performance‑Verschiebungen fälschlich den LVE‑Werten zugeschrieben werden.
Tests de charge et planification de la capacité
Ich führe periodisch moderate Lasttests durch, die reale Nutzung simulieren (Burst‑Traffic, Cache‑Miss‑Szenarien, Checkout‑Flows). Dabei beobachte ich, an welchem Limit zuerst Faults auftreten, und sammele Baselines pro Tarifstufe. Diese Werte helfen mir, Vertriebspakete belastbar zu beschreiben und Upgrade‑Empfehlungen faktenbasiert zu geben. Für Hosts mit heterogener Hardware (SATA vs. NVMe) halte ich pro Klasse eigene Default‑Schablonen bereit, damit die Performance je Node konsistent wirkt.
Zusammenfassung: So setze ich den LVE Manager gewinnbringend ein
Ich starte mit sauberen Standardpaketen, deaktiviere VMEM, setze vernünftige CPU‑ und RAM‑Grenzen und skaliere IO/IOPS nach Storageklasse, damit ich kalkulierbare Performance erhalte. Dann verknüpfe ich LVE‑Pakete mit den Panel‑Paketen, damit jeder Neuaccount sofort die passenden Limits trägt. Individuelle Abweichungen vergebe ich nur gezielt und zeitlich begrenzt, besonders für Kampagnen oder saisonale Spitzen. Monitoring ist kein Anhängsel: Ich werte Faults regelmäßig aus, passe Limits behutsam an und binde Kunden in ihre eigene Nutzung ein. Mit CageFS und optionalen Tools wie CLI und Governor halte ich die Plattform sicher, fair und reaktionsfähig, während ich gleichzeitig Support‑Aufwand senke und die Expérience client verbessere.
