CloudLinux LVE-Limits im Shared Hosting verstehen und prüfen

Was ein LVE im Shared Hosting begrenzt

Beim Shared Hosting teilen sich mehrere Kunden die Ressourcen eines Servers. CloudLinux kann die Nutzung eines Kundenkontos mit einem Lightweight Virtualized Environment, kurz LVE, begrenzen. Der Anbieter legt fest, welche Grenzen gelten. Sie sollen verhindern, dass ein Konto unbegrenzt Ressourcen beansprucht; umgekehrt kann auch die eigene Website an diese Grenzen stoßen.

Ein Limit beschreibt eine Obergrenze und ist nicht automatisch eine reservierte Leistung. Ein CPU-Limit bedeutet beispielsweise nicht, dass dir ein Prozessorkern exklusiv gehört oder eine bestimmte Antwortzeit zugesichert wird. Wie schnell eine Anwendung arbeitet, hängt auch von ihrer Aufgabe, der Hardware und weiteren Komponenten ab.

Ein LVE macht dein Hosting-Paket auch nicht zu einem eigenen Server. Der Anbieter betreibt weiterhin die gemeinsame Umgebung und bestimmt deren Konfiguration. Als Kunde kannst du die geltenden Werte und ihre Folgen nur insoweit selbst prüfen, wie dein Tarif und das Hosting-Panel entsprechende Informationen bereitstellen.

Davon zu unterscheiden ist CageFS: Es betrifft die Isolation der Dateisystemsicht, während LVE-Limits die Ressourcennutzung begrenzen. Beide Funktionen können sich ergänzen, sind aber nicht dasselbe. Welche Komponenten in deinem Angebot tatsächlich aktiv sind, kann dir der Anbieter bestätigen.

Eine vertiefende Einordnung der Komponenten findest du im Artikel zur Prozessisolation mit CloudLinux SecureLVE. Für die konkrete Fehlersuche ist dennoch die Konfiguration deines eigenen Pakets entscheidend: Oberfläche und Detailtiefe der Ressourcenanzeige können je nach Panel und Freischaltung abweichen.

Für wen gelten die Limits?

Entscheidend ist nicht nur die Höhe eines Limits, sondern auch sein Geltungsbereich. Betreibst du beispielsweise einen Blog und einen Shop unter demselben Hosting-Konto, können beide in einer kontobezogenen Konfiguration dasselbe Ressourcenbudget beanspruchen. Ein Import im Shop kann dann Kapazität belegen, die der Blog zur selben Zeit ebenfalls benötigt.

Das bedeutet nicht, dass jede langsame Seite durch ein anderes Projekt im Konto verursacht wird. Es erklärt aber, warum du bei einem Grenzereignis nicht nur die gerade betroffene Domain betrachten solltest. Auch geplante Aufgaben und andere Websites desselben Kontos können im fraglichen Zeitraum relevant sein.

CloudLinux dokumentiert mit Isolates außerdem eine Möglichkeit, Grenzen auf Website-Ebene zu setzen. Ob diese Funktion eingesetzt wird und wie die Zuordnung im jeweiligen Angebot aussieht, lässt sich aus der Bezeichnung CloudLinux allein nicht ableiten. Auch eine getrennte Betrachtung ersetzt daher nicht den Blick auf die konkreten Tarifbedingungen.

Frage den Anbieter vor einem Tarifvergleich möglichst konkret: Gelten SPEED, PMEM, IO, IOPS, EP und NPROC pro Hosting-Konto oder pro Website? Wenn mehrere Projekte ein Budget teilen, ist zusätzlich wichtig, welche Domains und Aufgaben diesem Budget zugeordnet sind. So vermeidest du, einen ausgewiesenen Wert versehentlich für jede einzelne Website einzuplanen.

Falls das Panel nur eine gemeinsame Statistik zeigt, hilft diese zunächst bei der zeitlichen Eingrenzung, aber nicht unbedingt bei der Zuordnung zu einer einzelnen Anwendung. Bitte den Support dann um Auskunft, welche Aufschlüsselung verfügbar ist und ob sich die Last einem Projekt oder einer Aufgabe zuordnen lässt.

CPU, Speicher und Zugriffslimits unterscheiden

Die verschiedenen Shared Hosting Limits begrenzen unterschiedliche Arten von Arbeit. SPEED steht für das CPU-Budget: Wird es ausgeschöpft, werden rechenintensive Prozesse gedrosselt und Anfragen können länger dauern. Ein CPU-Limit im Hosting ist damit nur eine mögliche Erklärung für langsame Seiten, nicht gleichbedeutend mit allen LVE-Grenzen.

PMEM begrenzt den physischen Speicher des LVE. Bei Speicherdruck kann zunächst Cache freigegeben werden; reicht das nicht, können Prozesse beendet werden. Der veraltete Wert VMEM für virtuellen Speicher ist davon zu unterscheiden. Ebenso ist das PHP-memory_limit nicht mit dem gesamten PMEM-Budget des LVE gleichzusetzen.

Bei Dateizugriffen messen IO und IOPS unterschiedliche Dinge: IO betrifft den Datendurchsatz, IOPS die Zahl der Lese- und Schreiboperationen pro Sekunde. Viele kleine Dateien können deshalb ein anderes Limit beanspruchen als wenige große Dateien. IO bezeichnet hier nicht die Geschwindigkeit deiner Internetverbindung.

EP zählt Eintritte in das LVE und ist keine allgemeine Grenze für gleichzeitige Besucher. Wie Eintritte gezählt werden, hängt unter anderem von Webserver und Prozessmodell ab. NPROC begrenzt dagegen Prozesse und Threads. Ist diese Grenze erreicht, können vorübergehend keine weiteren Prozesse erstellt werden; EP und NPROC sind deshalb nicht austauschbar.

Speicherplatz und Inodes sind verwandte, aber separate Tarifangaben. Eine volle Dateiquota oder eine ausgeschöpfte Inode-Grenze ist nicht automatisch ein CPU-, PMEM- oder EP-Problem. Welche dieser Werte du selbst im Panel siehst, hängt vom Anbieter und der bereitgestellten Oberfläche ab.

LVE-Limits und ihre Folgen im Überblick

Die LVE-Grenzen wirken nicht alle auf dieselbe Weise: Manche bremsen laufende Arbeit, andere verhindern neue Prozesse oder können bestehende Prozesse beenden. Die Tabelle hilft dir, eine angezeigte Ressource mit ihrem Verhalten und einer passenden Prüfspur zu verbinden. Die konkreten Grenzwerte legt dein Anbieter fest.

Beim PMEM-Limit zählt nicht nur der Speicher einzelner Anwendungsprozesse. Auch gemeinsam genutzter Speicher und Dateicache können einfließen; ob Cache angerechnet wird, hängt von der Konfiguration ab. Werden Prozesse beendet, sind HTTP-Fehler möglich, aber nicht zwangsläufig die sichtbare Folge.

Die beiden Dateizugriffsgrenzen beschreiben unterschiedliche Größen: IO begrenzt den Datendurchsatz, IOPS die Zahl der Operationen. Viele kleine Dateien können daher vor allem IOPS beanspruchen, während große Dateien hohen Durchsatz erzeugen können. IO steht hier nicht für die Netzwerkbandbreite; Zugriffe aus dem Dateicache zählen laut CloudLinux nicht zum IO-Limit.

CPU-Limit am Beispiel berechnen

Angenommen, dein Paket hätte ein SPEED-Limit von 150 Prozent. Da 100 Prozent rechnerisch einem Prozessorkern entsprechen, ergibt das ein CPU-Budget entsprechend anderthalb Kernen. Illustratives Rechenbeispiel, keine Messung. Der tatsächliche Wert deines Pakets kann anders ausfallen; maßgeblich ist die Angabe des Anbieters.

Das Beispiel beschreibt eine Obergrenze für die nutzbare CPU-Zeit, keine Reservierung eines exklusiven Kerns. Es bedeutet auch nicht, dass jeder einzelne Prozess anderthalb Kerne gleichzeitig nutzen kann. Wie sich das Budget auf laufende Arbeit verteilt, hängt unter anderem davon ab, wie viele Prozesse tatsächlich parallel Rechenzeit benötigen.

Aus 150 Prozent folgt weder eine garantierte Antwortzeit noch eine bestimmte Zahl gleichzeitig bedienbarer Besucher. Ein einfacher Aufruf kann wenig Rechenarbeit verursachen, ein dynamischer Aufruf dagegen deutlich mehr. Hinzu kommen mögliche Wartezeiten auf Dateizugriffe oder Datenbankarbeit, die ein höheres CPU-Budget nicht automatisch beseitigt.

Auch gleiche Prozentwerte auf unterschiedlichen Servern sind kein direkter Geschwindigkeitsvergleich: Prozessorkerne können sich in ihrer Leistung unterscheiden. Für die Bewertung deines CPU-Limits ist deshalb wichtiger, ob die Nutzung während eines konkreten Problems wiederholt an der Grenze liegt und passende Grenzereignisse sichtbar sind. Selbst dann solltest du weitere mögliche Ursachen prüfen.

Ressourcenanzeige richtig lesen

Falls dein Anbieter eine Ressourcenansicht freigeschaltet hat, beginne mit einem möglichst genau eingegrenzten Vorfall. Notiere Domain, Datum, Uhrzeit und Zeitzone sowie gegebenenfalls den angezeigten HTTP-Status. Beschreibe auch, was langsam war oder fehlschlug. Ohne diese Angaben lässt sich eine Spitze in der Statistik nur schwer einem konkreten Problem zuordnen.

Wähle anschließend denselben Zeitraum in der Anzeige und vergleiche für CPU, PMEM, IO, IOPS, EP und NPROC jeweils Nutzung, eingestelltes Limit und gegebenenfalls angezeigte Faults. Nicht jede Oberfläche zeigt alle Werte gleich an. Fehlen dir Statistiken oder ist unklar, auf welches Konto sie sich beziehen, frage beim Anbieter nach.

Achte auf die Zeitauflösung: Ein niedriger Stundenmittelwert kann eine kurze Spitze verdecken, bei der eine Grenze erreicht wurde. Wähle, sofern verfügbar, einen engeren Zeitraum oder eine feinere Darstellung. Vergleiche die Spitze mit der notierten Fehlerzeit, statt allein aus einem Tages- oder Stundenmittel zu schließen, dass kein Engpass vorlag.

Faults markieren Grenzereignisse, sind aber keine unmittelbare Zählung betroffener Besucher oder fehlgeschlagener Seitenaufrufe. Ein zeitlich passender Fault ist ein Hinweis, noch kein vollständiger Ursachenbeweis. Prüfe deshalb auch, ob zur selben Zeit ein Import, ein Backup, eine geplante Aufgabe oder eine Änderung an der Anwendung stattfand.

Die Oberfläche und ihre Funktionen hängen von Panel und Freischaltung ab; einen allgemeingültigen Menüpfad gibt es daher nicht. Für den technischen Hintergrund der Verwaltung bietet der Beitrag zum CloudLinux LVE Manager und zur Ressourcenverwaltung weitere Informationen. Administrative Konfigurationsschritte dort setzen allerdings entsprechende Rechte voraus und sind nicht automatisch für dein Kundenkonto verfügbar.

Langsame Seiten und Fehler einordnen

Ist dein CMS beim Bearbeiten oder bei dynamischen Seitenaufrufen langsam, vergleiche zuerst den betroffenen Zeitraum mit der CPU-Anzeige. Liegt die Nutzung wiederholt an der SPEED-Grenze und sind dazu passende Faults sichtbar, ist eine CPU-Drosselung plausibel. Die zeitliche Übereinstimmung macht sie zu einer Spur, beweist aber noch nicht, welche Aufgabe die Last verursacht hat.

Prüfe beispielsweise, ob zur selben Zeit geplante Aufgaben laufen oder ob eine Änderung an Erweiterungen mit dem Problem zusammenfällt. Auch Datenbankarbeit, Netzwerkprobleme oder eine langsam reagierende externe Schnittstelle können Seiten verzögern. Eine hohe CPU-Auslastung allein bedeutet deshalb weder, dass der Tarif falsch gewählt ist, noch dass eine bestimmte Erweiterung schuld sein muss.

Treten Fehler bei mehreren gleichzeitig eintreffenden dynamischen Anfragen auf, kann ein zeitgleicher EP-Fault weiterhelfen. Lang laufende Anfragen halten Eintritte länger belegt; zugleich kann ein Besucher mehrere Anfragen auslösen. EP ist daher keine Besucherzählung. Bei Apache ist HTTP 508 eine mögliche Folge einer überschrittenen EP-Grenze, aber der Status allein belegt die Ursache nicht.

Zeigt die Anzeige während eines Imports PMEM-Faults, kommt das LVE-Speicherlimit als Ursache infrage. Neben dem Import können gleichzeitig laufende PHP-Prozesse Speicher beanspruchen; ohne passende Prozessdaten bleibt offen, welche Aufgabe den Ausschlag gab. Auch ein HTTP-500- oder 503-Fehler kann andere Ursachen haben und ist für sich genommen kein Beweis für Speichermangel.

Der PHP-Wert memory_limit beantwortet diese Frage nicht allein: Er beschreibt nicht die gesamte Speichernutzung aller Aufgaben im LVE. Vergleiche deshalb den Importzeitpunkt mit PMEM-Nutzung und Faults und halte fest, welche anderen Aufgaben parallel liefen, bevor du eine Einstellung oder den Tarif änderst.

Hintergrundlast prüfen und Support einbeziehen

Läuft ein Backup oder Dateiimport langsam, betrachte IO und IOPS getrennt. IO begrenzt den Datendurchsatz bei Festplattenzugriffen, IOPS die Zahl der Lese- und Schreiboperationen pro Sekunde. Viele kleine Dateien können deshalb ein anderes Limit beanspruchen als die Übertragung weniger großer Dateien; IO ist dabei nicht die Internetbandbreite.

Ein Backup kann gleichzeitig CPU und Speicher benötigen. Prüfe daher neben IO und IOPS auch SPEED und PMEM für denselben Zeitraum, statt die Ursache allein aus der Dauer abzuleiten. Werden Zugriffe aus dem Dateicache bedient, zählen sie laut CloudLinux nicht zum IO-Limit; die angezeigte IO-Nutzung beschreibt also nicht jeden Dateizugriff gleichermaßen.

Lässt sich eine geplante Aufgabe verschieben, vergleiche ihren regulären Lauf in einer weniger stark belegten Phase mit einem ähnlichen früheren Zeitraum. Berücksichtige dabei Umfang und parallel laufende Aufgaben: Ein kleinerer Import ist kein direkter Vergleich für ein vollständiges Backup. Zusätzliche produktive Belastungstests oder das Löschen von Dateien sind für diese Einordnung nicht erforderlich.

Auch die Datenbanklast kann eine Rolle spielen, selbst wenn die angezeigte Web-CPU-Nutzung niedrig ist. Ihre Zuordnung zum Konto und mögliche separate MySQL-Grenzen hängen von der Konfiguration ab. Frage den Anbieter, welche Datenbankwerte du im Panel sehen kannst und ob Datenbankarbeit dem LVE zugerechnet oder gesondert begrenzt wird.

Für eine Supportanfrage sind Domain, Zeitpunkt mit Zeitzone, beobachteter HTTP-Status und der betroffene Vorgang hilfreich. Ergänze die im gleichen Zeitraum sichtbaren Limits, Nutzungswerte und Faults sowie bekannte Imports oder Backups. Bitte um die Zuordnung der Grenzereignisse und, falls verfügbar, um eine Auswertung von Prozess-Snapshots; so lässt sich die Vermutung gezielter prüfen.

Optimieren, upgraden oder Server wechseln?

Beginne mit der Optimierung einer identifizierten Aufgabe, wenn sich ihr Ressourcenbedarf nachvollziehbar senken lässt. Prüfe etwa Cache-Einstellungen, Erweiterungen und parallel geplante Hintergrundjobs. Vergleiche anschließend ähnliche Zeiträume und achte sowohl auf die Nutzerprobleme als auch auf die betroffenen Ressourcenwerte. Eine einzelne Änderung macht dabei leichter erkennbar, was sich tatsächlich verändert hat.

Ein Upgrade ist eine Alternative, wenn wiederkehrende, belegte Spitzen trotz angemessener Optimierung an die zugeteilten Grenzen stoßen. Frage vorab nach den konkreten Werten für SPEED, PMEM, IO, IOPS, EP und NPROC. Vergleiche nicht nur Paketnamen: Ein höheres CPU-Limit beseitigt weder eine unabhängig bestehende EP-Grenze noch einen Mangel an LVE-Speicher.

Zum Tarifvergleich gehört auch der Geltungsbereich. Teile dem Anbieter mit, wie viele Websites dein Konto enthält, und frage, ob sie ein gemeinsames Ressourcenbudget nutzen oder ob Grenzen pro Website gelten. CloudLinux bietet mit Isolates eine Möglichkeit für Letzteres; aus dem Produktnamen allein folgt aber nicht, dass dein Angebot sie verwendet.

Ein VPS oder Managed Server kann mehr Gestaltungsspielraum bieten, ist aber keine automatische Lösung für jede langsame Website. Entscheidend sind die verfügbaren Ressourcen, die tatsächliche Last und das Betriebsmodell: Bei einem VPS musst du insbesondere klären, welche Administration du selbst übernimmst; bei einem Managed Server, welche Aufgaben der Anbieter abdeckt.

Bleibt die Ursache ungeklärt, ist eine Rückfrage mit den gesammelten Zeitpunkten und Faults sinnvoller als ein Wechsel auf Verdacht. Auch unterhalb eines LVE-Limits können Anwendung, Netzwerk oder Datenbank bremsen. Lass dir vor einer Entscheidung bestätigen, welche Statistiken und Unterstützung im jeweiligen Angebot verfügbar sind.