Zum Inhalt springen 
CloudLinux MySQL Governor begrenzt die Datenbanklast pro Account und verteilt sie fair, damit einzelne Abfragen nicht das gesamte Hosting verlangsamen. Ich nutze den MySQL Governor, um CPU, READ und WRITE je Nutzer in Echtzeit zu beobachten und bei Überschreitungen automatisch zu drosseln.
Zentrale Punkte
- Pro Account statt globaler Limits
- CPU/READ/WRITE getrennt steuern
- Modi Monitor-only und Abusen li>LVE als zweite Schutzstufe
- CLI-Tools für Kontrolle
Warum einzelne Queries alles ausbremsen
In Shared-Hosting-Umgebungen erzeugen meist wenige Abfragen die meiste Last, nicht die Masse der Datenbanken. Ich sehe oft, dass eine fehlerhafte Query oder ein Plugin mit hohem I/O plötzlich die CPU-Zeit monopolisiert und die Latenz für andere Nutzer spürbar steigt. Genau hier greift der Governor ein, weil er Last pro Nutzer sichtbar macht und nicht nur den Gesamtdurchschnitt betrachtet. So verhindere ich, dass ein „lauter Nachbar“ alle anderen Projekte ins Stocken bringt, obwohl deren Workloads gesund sind. Mit klaren Grenzwerten und einer fairen Verteilung halte ich Antwortzeiten planbar und entziehe überzogenen Zugriffen die Grundlage.
So arbeitet MySQL Governor im Alltag
Ich starte oft im Monitor-only-Modus, um reale Nutzung zu messen, ohne einzugreifen. Danach aktiviere ich den Abusen-Modus, der übermäßige Konten automatisch in eine begrenzte Umgebung verschiebt und so die Wirkung sofort eindämmt. Die Messung basiert auf Thread-Statistiken pro MySQL/MariaDB-Verbindung, wodurch CPU-, Lese- und Schreibanteile je Nutzer nachvollziehbar werden. Bei anhaltender Überlast greift zusätzlich die zugeordnete LVE, wodurch Prozesse dieser Accounts weiter gebremst werden. Dieser zweistufige Ablauf verhindert Eskalationen, entschärft Peaks und schützt unbeteiligte Projekte zuverlässig.
Grenzwerte und Zeitfenster sinnvoll wählen
Ich setze Limits über mehrere Intervalle, damit ich kurzfristige Peaks toleriere, dauerhafte Überlast aber zuverlässig stoppe. Kurze Zeitfenster dürfen höher liegen, mittlere mäßig, lange klar strenger, und sie sollten unter den globalen LVE-Grenzen bleiben. CPU messe ich als Prozentsatz pro Kern; bei acht Kernen entsprechen 100% einem vollen Kern, wodurch Verteilung und Fairness transparent bleiben. READ und WRITE bewerte ich anhand realer Platten-I/O, also ohne Cache-Treffer, damit ich die tatsächliche Last auf den Storage sehe. Für eine saubere Gesamtkonfiguration orientiere ich mich an bewährten LVE-Regeln und Details wie in LVE-Limits richtig konfigurieren beschrieben.
Intervalle nach Tageszeit und Profilen planen
Ich hinterlege gern tageszeitabhängige Profile: Im Kernzeitraum lasse ich kurze Intervalle etwas großzügiger zu, um legitime Traffic-Peaks aufzufangen (z. B. Shop-Flashsales). In den Abend- und Nachtstunden ziehe ich vor allem die langen Intervalle straffer, damit langlaufende Jobs nicht unbemerkt die Platte ausreizen. Für Batch-Fenster definiere ich eigene Profile mit etwas mehr WRITE, aber begrenzter CPU, damit Importe zwar zügig, aber nicht monopolistisch durchlaufen. Wichtig bleibt: Ich ändere nie alle Regler gleichzeitig. Erst passe ich CPU an, beobachte, dann READ/WRITE. Jede Änderung bekommt einen klaren Beobachtungszeitraum, damit Ursache und Wirkung sauber trennbar sind.
CLI-Tools und schnelle Diagnose
Ich analysiere auffällige Konten mit dbtop in Echtzeit, schreibe Limits mit dbctl fort und schaue historische Spuren über lveinfo –dbgov ein. Diese Werkzeuge liefern mir innerhalb von Sekunden die relevanten Fakten zu Spitzenwerten, langlaufenden Queries und Verbindungszahlen je Nutzer. So erkenne ich, ob vor allem CPU oder I/O limitiert, ob Verbindungen ausufern oder ob einzelne Tabellen Abfragen stauen. Aus den Mustern leite ich angepasste Schwellenwerte je Intervall ab und teste Änderungen zunächst in Monitor-only. Erst wenn die Kurven plausibel fallen, aktiviere ich die Drosselung dauerhaft.
| Tool | Zweck | Beispiel |
|---|---|---|
| dbtop | Live-Ansicht pro Nutzer/Thread | dbtop –by-user |
| dbctl | Limits setzen und Modi steuern | dbctl set userX cpu=120 read=8 write=6 |
| lveinfo –dbgov | Historie und Verstöße prüfen | lveinfo –dbgov –id userX –period 1h |
Fehlersuche: typische Muster und schnelle Gegenmaßnahmen
Wenn CPU eines Accounts hochschießt, finde ich oft Muster wie SELECT *, fehlende WHERE-Klauseln, komplexe ORDER BY mit großen Resultsets oder N+1-Queries aus ORMs. Bei I/O sehe ich Vollscans ohne passende Indizes, wiederholte LIKE ‚%…%‘ oder JOINs auf nicht indizierten Spalten. Mein Ablauf: betroffene Tabellen identifizieren, Abfrageplan prüfen, fehlende Indizes ergänzen und die Query verschlanken (nur benötigte Spalten, pagination mit LIMIT/OFFSET oder Cursor-Ansätzen). Parallel setze ich für diesen Nutzer temporär strengere kurze Intervalle, damit der Peak sofort entschärft wird, und lockere diese wieder, sobald der Fix produktiv ist und die Kurve stabil fällt.
Zusammenspiel mit LVE: zweistufige Kontrolle
Ich betrachte MySQL Governor als erste Datenbankschutzschicht und LVE als zweite Bremse, falls Last länger anhält. Der Governor drosselt gezielt die DB-Aktivität, während LVE darüber hinaus CPU, RAM und IO des Kontos insgesamt eng führt. Diese Kombination verhindert, dass ein Konto sich durch reines Wiederholen kurzer Queries aus der Kontrolle windet. Bleibt die Aktivität hoch, greift LVE und fährt die Prozesspriorität des Kontos herunter, wodurch die Datenbank spürbar entlastet. So bleibt die Servicequalität für alle Kunden verlässlich, selbst während Lastwellen und Traffic-Peaks.
Grenzwerte in der Praxis: Beispielwerte
Ich starte bei typischen Shared-Servern mit CPU-Limits zwischen 80–150% je Account im kurzen Intervall und reduziere im langen Intervall deutlich. READ/WRITE beginne ich oft bei 4–12 MB/s kurzfristig und ziehe langfristig enger, damit die Platte nicht in dauerhafte Wartezeiten kippt. Die Zahl gleichzeitiger Verbindungen deckle ich gerne bei 30, weil überzogene Verbindungen schnell Thread-Pools erschöpfen. Solche Startwerte taugen als Basis, doch ich passe sie nach realen Spuren aus dbtop und lveinfo an. Wichtig bleibt: kurzatmige Spitzen darf ich zulassen, dauerhafte Ausreizung unterbinde ich konsequent.
Ausnahmen, Whitelists und Wartungsfenster
Einzelne Konten brauchen phasenweise mehr Luft: große Importe, Shop-Migrationen, Reindexing. Ich plane solche Aktionen in Zeitfenstern außerhalb der Kernnutzung und setze vorab temporär höhere Limits pro Nutzer. Nach Abschluss stelle ich per Skript die Standardwerte wieder her. Ebenso sinnvoll ist eine kleine Whitelist für systemrelevante Konten, die nie drosseln sollen (z. B. interne Service-User). Ich dokumentiere jede Ausnahme mit Start-/Endzeit und Zielwerten, damit spätere Analysen die Abweichung erklären können. So bleibt Governance nachvollziehbar, ohne legitime Wartungsarbeiten zu behindern.
WordPress und Plugins: typische Auslöser entschärfen
In CMS-Setups sehe ich oft teure JOINs, dynamische Widgets ohne Cache und Cron-Jobs, die stündlich volle Tabellen scannen. Der Governor schützt hier zuverlässig, aber ich löse die Ursache zusätzlich an der Anwendung. Ich aktiviere Object-Cache, reduziere Suchabfragen und nutze wo sinnvoll Connection-Pooling, um Connect/Disconnect-Stürme zu vermeiden. Kombiniert mit klaren CPU/IO-Limits senke ich Antwortzeiten spürbar und halte die Last kontrollierbar. Dieser Mix spart Supporttickets und entschärft Peaks, bevor sie den Server belasten.
Schema- und Index-Hygiene in der Praxis
Ich prüfe regelmäßig, ob Tabellen und Indizes noch zum Zugriffsmuster passen. Neue Features und Plugins verändern Queries oft subtil: ein zusätzlicher Filter, ein anderes Sortierkriterium – und schon greift der alte Index nicht mehr. Ich priorisiere deshalb Indizes für häufige WHERE-Spalten, reduziere überlappende Indizes und ersetze LIKE-Prefix-Suchen durch zielgenauere Felder. Für Archivtabelle nutze ich Partitionskonzepte oder Zeitstempel-Filter, um Vollscans zu verhindern. Der Governor fängt Folgen schlechter Schemas ab, aber am effizientesten ist es, die Daten zugriffsfreundlich zu strukturieren.
Verbindungsmanagement: 500-Fehler vermeiden
Zu viele gleichzeitige Verbindungen reißen Services oft in Time-outs, die als 500-Fehler sichtbar werden. Ich prüfe zuerst die Verbindungsrate je Nutzer und die Auslastung des Thread-Pools. Falls Anzeichen für Connection-Stürme bestehen, setze ich Limits enger und führe Caching auf Query- oder Objekt-Ebene ein. Ergänzend erläutert der Beitrag zu 500-Fehler durch Verbindungen typische Ursachen und Maßnahmen gegen diesen Engpass. In Summe sichere ich den MySQL-Stack ab und halte die Latenz berechenbar.
Pooling und Keep-Alive richtig dosieren
Ich dimensioniere Pools klein, aber konstant: genug, um typische Parallelität abzudecken, ohne den Server mit Leerlauf-Sessions zu blockieren. Lange Keep-Alive-Zeiten glätten Lastspitzen, dürfen aber nicht dazu führen, dass viele schlafende Verbindungen Ressourcen binden. Ich messe deshalb Verweildauer und Leerlauf pro Account und reguliere Poolgrößen sowie Session-Timeouts entsprechend. In Verbindung mit dem Governor verhindere ich so, dass wildes Auf- und Abbauen von Verbindungen CPU frisst, während gleichzeitig übergroße Pools den Thread-Pool unnötig belegen.
Monitoring-Kennzahlen richtig lesen
Ich unterscheide klar zwischen CPU und I/O, weil beide Ressourcen völlig unterschiedlich limitieren. Steigt CPU stark ohne passende I/O-Werte, dann blockiert oft Logik, Parsing oder ein ineffizienter Plan; bei hoher I/O mit niedriger CPU deuten Vollscans oder fehlende Indizes auf das Nadelöhr. READ/WRITE bewerte ich stets ohne Cache, damit ich echte Plattenlast erkenne und nicht nur Speicherzugriffe. Außerdem schaue ich auf Verbindungsdauer, aktive Threads und Query-Länge, um langsame Läufer früh zu fassen. Aus diesen Mustern folgt, welche Grenze ich anziehe und welches Intervall ich straffer einstelle.
Hardware- und Engine-Faktoren berücksichtigen
Die Storage-Klasse bestimmt, welche Grenzwerte praktikabel sind. Auf NVMe kann ich kurzfristig höhere READ/WRITE-Werte zulassen, auf HDD plane ich konservativer und halte lange Intervalle strenger. Ich beachte außerdem, wie die Engine puffert: Aggressive Hintergrundschreiber können Peaks glätten, aber auch scheinbar „ruhige“ Phasen produzieren, in denen Writes nachlaufen. Deshalb korreliere ich Governor-Metriken mit physischem I/O und Wartezeiten am Block-Device. Ziel ist stets ein stabiler Median statt maximale Durchsatzwerte auf Kosten der Latenz.
Monitor-only und Abusen im Vergleich
Ich nutze den Monitor-only-Modus, um reale Nutzungsprofile zu sammeln und Basislinien abzuleiten. Sobald ich Grenzwerte plausibel festgelegt habe, schalte ich auf Abusen, damit der Governor Konten mit Überlast automatisch drosselt. Der erste Modus reduziert Falschalarme, der zweite verhindert Kollateralschäden während echter Spitzen. Je nach Erfahrungsstand kann ich mit strengeren langen Intervallen arbeiten und in kurzen Intervallen etwas mehr Luft geben. Diese Abfolge sorgt dafür, dass Limits nicht aus dem Bauch entstehen, sondern einer Messung folgen.
Rollout-Plan und Kommunikation
Ich führe den Governor nie „Big Bang“ ein. Der Ablauf ist bewährt: 1) Inventur der aktiven Accounts, grobe Clusterung nach Lastprofilen. 2) Monitor-only für mindestens ein bis zwei Wochen, um Wochenmuster zu erfassen. 3) Festlegen von Basislimits pro Cluster und kontrollierter Rollout in Wellen, jeweils mit enger Beobachtung der KPIs (Fehlerquote, P95-Latenz, Abbruchraten). 4) Feinjustierung und Dokumentation von Ausnahmen. Parallel informiere ich Kunden proaktiv über das Ziel „Fair Share“, typische Ursachen von Drosselungen und sinnvolle Optimierungen. Transparenz senkt Rückfragen und erhöht die Akzeptanz der Limits.
Replikation, Backups und Sondernutzer sichern
Systemnahe Nutzer wie Replikations- oder Backup-User dürfen nicht unerwartet gebremst werden. Ich ordne solche Konten klar zu, dokumentiere sie und nehme sie aus automatischen Drosselungen heraus. Für Backups plane ich Lesegrenzen, die unterhalb der Storage-Komfortzone liegen, damit die Nutzerlast parallel nicht leidet. Bei Replikation achte ich darauf, dass Aufholvorgänge nicht die Produktionslast gefährden: kurze Intervalle etwas großzügiger, lange Intervalle konservativ, damit anhaltendes Aufholen nicht zur Dauerbremse wird. Wichtig bleibt die saubere Trennung zwischen Service- und Kundenkonten, damit die Metriken eindeutig bleiben.
Notfallverfahren bei akuter Überlast
Kommt es trotz Limits zu spürbarer Degradation, arbeite ich ein Playbook ab: 1) In dbtop den Top-Account identifizieren und dessen Limits kurzfristig verschärfen. 2) Verbindungsobergrenze für diesen Nutzer reduzieren, um den Thread-Pool zu entlasten. 3) Langläufer sichtbar machen, auffällige Queries priorisiert optimieren oder pausieren. 4) Bei breiter Systemlast LVE-Grenzen des Übeltäters temporär absenken, um die Plattform zu stabilisieren. 5) Nach Beruhigung schrittweise zurückdrehen und die Ursache dauerhaft beheben (Index, Cache, Code). Ich protokolliere jede Maßnahme mit Zeitpunkt und gemessener Wirkung, damit künftige Einsätze schneller werden.
Kurz zusammengefasst: praktikable Leitlinien
Ich setze auf klar getrennte Limits für CPU, READ und WRITE, weil jede Ressource unterschiedlich wirkt. Ich beginne konservativ, messe Effekte im Monitor-only-Modus und ziehe Grenzen im Abusen-Modus an, sobald die Kurven belastbar zeigen, wohin die Reise geht. Ich halte langfristige Intervalle strenger und bleibe unter den globalen LVE-Grenzen, damit die zweite Schutzstufe bei Bedarf sicher greift. Ich behalte die Verbindungszahl im Blick, starte mit 30 Sessions je Account und reguliere abhängig von Workload und Tageszeit. Ich kombiniere technische Steuerung mit Ursachenarbeit an der Anwendung, denn so halte ich die Datenbank verlässlich, fair und flink für alle Projekte auf demselben Server.
