{"id":21605,"date":"2026-09-20T18:18:10","date_gmt":"2026-09-20T16:18:10","guid":{"rendered":"https:\/\/webhosting.de\/linux-cgroup-cpu-controller-kontrolle\/"},"modified":"2026-09-20T18:18:10","modified_gmt":"2026-09-20T16:18:10","slug":"controlo-do-controlador-de-cpu-do-cgroup-do-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-cgroup-cpu-controller-kontrolle\/","title":{"rendered":"O controlador de CPU cgroup do Linux em pormenor: controlar o desempenho com precis\u00e3o"},"content":{"rendered":"<p>Der Linux cgroup <strong>CPU Controller<\/strong> steuert, wie viel Rechenzeit Dienste, Container und Prozesse erhalten, und macht Leistung gezielt planbar. Ich erkl\u00e4re konkret, wie Gewichtung, Quoten und Praktiken zusammenspielen, damit du CPU-Zeit sicher zuteilst und Engp\u00e4sse vermeidest.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n<ul>\n  <li><strong>Gewichtung<\/strong> versus <strong>Limit<\/strong> verstehen: fair teilen oder harte Obergrenze<\/li>\n  <li><strong>cgroup v2<\/strong> bevorzugen: klare Semantik, konsistente Hierarchie<\/li>\n  <li><strong>cpu.weight<\/strong> und <strong>cpu.max<\/strong>: die zwei Stellhebel<\/li>\n  <li><strong>systemd<\/strong> nutzen: Regeln pro Dienst setzen<\/li>\n  <li><strong>Monitoring<\/strong> und <strong>Transparenz<\/strong>: cpu.stat und PSI lesen<\/li>\n<\/ul>\n\n<h2>cgroups verstehen: Prozessgruppen und Ziele<\/h2>\n<p>Ich fasse Prozesse in <strong>Gruppen<\/strong> zusammen und steuere dar\u00fcber Ressourcen wie CPU, Speicher und I\/O in sauber abgegrenzten Hierarchien. Statt einzelne PIDs zu jonglieren, ordne ich komplette Dienste, Container oder Worker-Pools einer Control Group zu und lege klare Regeln fest. So verhindere ich, dass ein ausufernder Task die Maschine ausbremst, w\u00e4hrend wichtige Komponenten reagieren m\u00fcssen. Gerade im Hosting-Kontext zahlt sich diese Herangehensweise aus, weil viele Mandanten und Dienste auf gleicher Hardware laufen. Einen guten \u00dcberblick zur praktischen Einordnung liefert dieser Beitrag zu <a href=\"https:\/\/webhosting.de\/cgroups-hosting-resource-isolation-linux-containerlimits-serverboost\/\">cgroups und Hosting<\/a>, der die Trennung von Lasten nachvollziehbar macht.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/cgroup-cpu-kontrolle-8723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wie der CPU-Controller arbeitet<\/h2>\n<p>Der CPU-Controller teilt <strong>Rechenzeit<\/strong> \u00fcber zwei Mechanismen zu: relative Gewichtung und absolute Bandbreitenbegrenzung. Gewichtung bedeutet, dass Gruppen im Verh\u00e4ltnis zueinander CPU-Anteile bekommen, sobald Konkurrenz entsteht; h\u00f6here Werte gewinnen dann h\u00e4ufiger Zeitscheiben. Ein Limit per Quote deckelt den Verbrauch in einem festen Zeitfenster, auch wenn keine Konkurrenz besteht. Ich w\u00e4hle Gewichtung, wenn Fairness und dynamische Auslastung im Vordergrund stehen, und setze Quoten, wenn eine harte Obergrenze unverr\u00fcckbar bleiben muss. Die Kernel-Dokumentation stellt diesen Unterschied klar dar und zeigt, wie beide Mechanismen zusammen ein schl\u00fcssiges Steuerungsmodell ergeben [1].<\/p>\n\n<h2>cgroup v1 vs. v2: Unterschiede und Dateien<\/h2>\n<p>Mit <strong>cgroup v2<\/strong> verwalte ich CPU-Regeln einheitlich und \u00fcbersichtlicher gegen\u00fcber der \u00e4lteren v1-Variante. In v1 nutzte ich verschiedene Dateien je Controller; in v2 konzentriere ich mich auf cpu.weight f\u00fcr relative Priorit\u00e4t und cpu.max f\u00fcr ein hartes Bandbreitenlimit. Diese klare Trennung verk\u00fcrzt Einrichtungszeit, vermeidet Missverst\u00e4ndnisse und erleichtert Audits. In Hosting-Szenarien mit vielen Containern sorgt die v2-Hierarchie f\u00fcr nachvollziehbare Regeln \u00fcber alle Ebenen. Eine Einsch\u00e4tzung zur Praxis liefert der Beitrag zu <a href=\"https:\/\/webhosting.de\/cgroup-v2-cloudlinux-shared-hosting-stabil\/\">cgroup v2 im Hosting<\/a>, der auf konsistente Steuerung bei gemeinsam genutzter Hardware eingeht.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Thema<\/th>\n      <th>cgroup v1<\/th>\n      <th>cgroup v2<\/th>\n      <th>Typische Parameter<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CPU-Gewichtung<\/td>\n      <td>cpu.shares<\/td>\n      <td>cpu.weight<\/td>\n      <td><code>cpu.weight<\/code> (Standard oft 100)<\/td>\n    <\/tr>\n    <tr>\n      <td>CPU-Quote\/Limits<\/td>\n      <td>cpu.cfs_quota_us + cpu.cfs_period_us<\/td>\n      <td>cpu.max<\/td>\n      <td><code>cpu.max<\/code> (z. B. 20000 100000)<\/td>\n    <\/tr>\n    <tr>\n      <td>Hierarchie<\/td>\n      <td>Getrennte Controller<\/td>\n      <td>Einheitliche Baumstruktur<\/td>\n      <td>Gemeinsame Regeln je Ebene<\/td>\n    <\/tr>\n    <tr>\n      <td>Echtzeit<\/td>\n      <td>Separater rt-Controller<\/td>\n      <td>Einschr\u00e4nkungen f\u00fcr RT<\/td>\n      <td>Siehe Kernel-Hinweise [1]<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>F\u00fcr Administratoren z\u00e4hlt, dass <strong>Konsistenz<\/strong> im Regelwerk Fehler reduziert und \u00c4nderungen schneller durchgreifen. Ich dokumentiere Parameter an den Gruppenknoten, damit jede Person die aktuelle Wirkung erkennt. Bei Migrationen von v1 pr\u00fcfe ich \u00c4quivalente sorgf\u00e4ltig, vor allem Shares zu Weight und CFS-Quota zu cpu.max. Erst wenn Testlasten erwartungsgem\u00e4\u00df reagieren, verschiebe ich produktive Dienste in die neue Hierarchie. Diese disziplinierte Umstellung spart sp\u00e4ter viele Supportzyklen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/LinuxCPUcgroupBesprechung_4523.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hierarchie, Subtrees und Delegation<\/h2>\n<p>In cgroup v2 steuere ich Controller <em>pro Ebene<\/em> und delegiere sie nach Bedarf weiter. \u00dcber <code>cgroup.subtree_control<\/code> aktiviere ich den CPU-Controller f\u00fcr Kindknoten; systemd \u00fcbernimmt das in der Regel automatisch, wenn ich CPU-Properties setze. Wichtig: In v2 halte ich Prozesse idealerweise in <strong>Blattgruppen<\/strong> und nicht in Zwischenknoten. So bleiben Regeln eindeutiger, und die Lastverteilung folgt klar der Baumstruktur. In komplexen Setups ordne ich ganze Dienste Slices zu (z. B. <code>tenant-a.slice<\/code>), darunter Services und Worker-Pools. Diese saubere Trennung erleichtert Delegation an Teams, die in \u201eihren\u201c Subtrees arbeiten, ohne globale Policies zu verletzen.<\/p>\n\n<h2>Wichtige Parameter: cpu.weight und cpu.max<\/h2>\n<p>Ich nutze <strong>cpu.weight<\/strong>, um Dienste relativ zu priorisieren: Erh\u00e4lt Service A ein h\u00f6heres Gewicht als Service B, bekommt A unter Last h\u00e4ufiger CPU-Zeiten. Der Standard in v2 liegt h\u00e4ufig bei 100; gr\u00f6\u00dfere Werte bevorzugen die jeweilige Gruppe, ich bleibe aber innerhalb sinnvoller Spannen, um das Verh\u00e4ltnis kontrollierbar zu halten. F\u00fcr harte Deckelung schreibe ich in <code>cpu.max<\/code> eine Quote und Periode, zum Beispiel <code>20000 100000<\/code> f\u00fcr ungef\u00e4hr 20 Prozent eines vCPU-Slots. Mit <code>max<\/code> als erstem Wert hebe ich die Deckelung auf, lasse aber die Periode bestehen, was Diagnosen vereinfacht. Red Hat dokumentiert g\u00e4ngige Einstellungen verst\u00e4ndlich und zeigt die Auswirkungen im Betrieb [2].<\/p>\n\n<h2>Erg\u00e4nzende Stellschrauben: cpu.weight.nice und UClamp<\/h2>\n<p>F\u00fcr Teams, die von der klassischen <code>nice<\/code>-Semantik kommen, bietet v2 mit <code>cpu.weight.nice<\/code> eine praktische Br\u00fccke: Ich kann Gruppen im Bereich <code>-20..19<\/code> einstufen, der intern auf die Weight-Skala abgebildet wird. So bleiben relative Erwartungen (\u201eein bisschen bevorzugen\u201c, \u201eleicht drosseln\u201c) konsistent, ohne jedes Mal konkrete Gewichte festzulegen. Dar\u00fcber hinaus setze ich bei Bedarf <strong>Utilization Clamping<\/strong> via <code>cpu.uclamp.min<\/code> und <code>cpu.uclamp.max<\/code>, um eine Mindest- bzw. Obergrenze f\u00fcr die effektive CPU-Auslastung auf Scheduler-Ebene vorzugeben. Damit stelle ich z. B. sicher, dass ein latenzkritischer Dienst auch bei geringer Threadzahl nicht unter die ben\u00f6tigte Grundauslastung f\u00e4llt, oder dass Batch-Jobs keinen zu hohen Boost erhalten. Diese Feineinstellung erg\u00e4nzt Gewichtung und Quoten, ersetzt sie aber nicht: Ich messe immer, wie sich UClamp mit meiner Governor- und Energiepolitik vertr\u00e4gt, bevor ich es breit ausrolle.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-cgroup-cpu-control-7895.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planung f\u00fcr Workloads: Fairness versus harte Grenzen<\/h2>\n<p>Ich entscheide bewusst, ob <strong>Fairness<\/strong> oder strikte Obergrenzen Vorrang haben. F\u00fcr latenzkritische Webdienste erh\u00f6he ich das Gewicht leicht, damit sie bei Konkurrenz bevorzugt laufen, ohne andere Gruppen \u00fcberm\u00e4\u00dfig zu benachteiligen. F\u00fcr rechenintensive Batch-Jobs setze ich zus\u00e4tzlich eine Quote, damit sie nie zu viel Zeit belegen, selbst wenn das System ansonsten Leerlauf hat. Datenbanken halte ich moderat gewichtet und beobachte, wie Checkpoints, Rebuilds oder gro\u00dfe Abfragen wirken; bei Bedarf passe ich zeitlich begrenzt an. Diese Regeln kombiniere ich mit Alarmen, damit ich fr\u00fch reagiere, bevor Latenzen eskalieren.<\/p>\n\n<h2>Quotenverhalten auf Multicore und Periodenwahl<\/h2>\n<p>Ein h\u00e4ufiger Stolperstein ist die Interpretation von <strong>Quoten auf Multicore-Systemen<\/strong>. Eine Quote bezieht sich auf die <em>Gesamtrechenzeit<\/em> der Gruppe pro Periode, nicht auf einzelne Kerne. <code>CPUQuota=200%<\/code> oder <code>cpu.max = 200000 100000<\/code> erlauben grob zwei CPU-Sekunden pro 100 ms Periode \u2013 verteilt \u00fcber alle Threads\/Kerne. Das kann bedeuten, dass viele Threads kurzzeitig parallel laufen, bis die Gruppe in der aktuellen Periode \u201eaufgebraucht\u201c ist und gedrosselt wird. Ich vermeide Missverst\u00e4ndnisse, indem ich Quoten stets in \u201eCPU-Slots\u201c denke und sie an die Parallelit\u00e4t des Dienstes anpasse.<\/p>\n<p>Die Standardperiode liegt h\u00e4ufig bei <strong>100 ms<\/strong>. Engere Perioden (<em>z. B.<\/em> 50 ms) lassen Drosselung schneller greifen, k\u00f6nnen aber Mikro-Jitter erzeugen; weitere Perioden gl\u00e4tten, reagieren jedoch tr\u00e4ger. Unter systemd passe ich das mit <code>CPUQuotaPeriodSec=<\/code> an und verifiziere, ob Latenzspitzen oder Throughput-Ziele besser getroffen werden. F\u00fcr interaktive Dienste messe ich End-to-End-Latenz, f\u00fcr Batch orientiere ich mich an Gesamtdurchsatz und Fairness gegen\u00fcber Nachbarn.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_cgroup_cpu_controller_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praxis: Einrichtung mit systemd und cgroup v2<\/h2>\n<p>Unter systemd setze ich Regeln je Dienst, weil <strong>Dienstdateien<\/strong> reproduzierbare Konfiguration erm\u00f6glichen. Mit <code>systemctl set-property<\/code> \u00e4ndere ich laufend, mit Drop-In-Dateien versioniere ich die Einstellungen sauber. Ein Beispiel: <code>systemctl set-property --runtime nginx.service CPUWeight=150<\/code> priorisiert NGINX leicht; <code>systemctl set-property --runtime batch.service CPUQuota=20%<\/code> deckelt Batch-Jobs. Dauerhaft trage ich in <code>\/etc\/systemd\/system\/service.d\/limits.conf<\/code> entsprechende Optionen ein und re-loade die Units. F\u00fcr einen praktischen Einstieg lohnt ein Blick auf diese Anleitung zu <a href=\"https:\/\/webhosting.de\/systemd-resource-control-linux-dienste-begrenzen-rack\/\">systemd-Resource-Control<\/a>, die die h\u00e4ufigsten Optionen kurz zusammenfasst.<\/p>\n\n<pre><code># Beispiele f\u00fcr systemd v245+ mit cgroup v2\n# Relative Priorisierung\nsystemctl set-property --runtime nginx.service CPUWeight=150\n\n# Harte Obergrenze\nsystemctl set-property --runtime batch.service CPUQuota=20%\n\n# Kombination in einer Drop-In-Datei\nmkdir -p \/etc\/systemd\/system\/php-fpm.service.d\ncat &lt;&lt; 'EOF' &gt; \/etc\/systemd\/system\/php-fpm.service.d\/cpu.conf\n[Service]\nCPUWeight=120\nCPUQuota=50%\nEOF\nsystemctl daemon-reload\nsystemctl restart php-fpm.service\n<\/code><\/pre>\n\n<h2>Slices f\u00fcr Tenants und Teams<\/h2>\n<p>F\u00fcr Mandanten- oder Teamgrenzen nutze ich <strong>Slices<\/strong> als organisatorische Klammer. Ein Slice kapselt mehrere Services und Scopes, die gemeinsam reglementiert werden. So vergebe ich Budgets pro Kunde, ohne jede Unit einzeln zu pflegen, und delegiere \u00c4nderungen kontrolliert.<\/p>\n<pre><code># Tenant-Slice mit Standardregeln\nmkdir -p \/etc\/systemd\/system\/tenant-a.slice.d\ncat &lt;&lt; 'EOF' &gt; \/etc\/systemd\/system\/tenant-a.slice.d\/cpu.conf\n[Slice]\nCPUWeight=120\nCPUQuota=150%\n# Optional: Periode f\u00fcr feineres Drosseln\nCPUQuotaPeriodSec=100ms\nEOF\nsystemctl daemon-reload\nsystemctl restart tenant-a.slice\n<\/code><\/pre>\n<p>Alle Dienste unter <code>tenant-a.slice<\/code> erben diese Vorgaben. F\u00fcr kurzzeitige Peaks erh\u00f6he ich das Gewicht tempor\u00e4r, lasse die Quote aber stabil, damit Nachbarsysteme nicht verdr\u00e4ngt werden.<\/p>\n\n<h2>Monitoring und Troubleshooting<\/h2>\n<p>Ich \u00fcberpr\u00fcfe Wirkung und Seiteneffekte mit <strong>Transparenz<\/strong> in Metriken. Die Dateien <code>cpu.stat<\/code> und <code>cpu.pressure<\/code> (PSI) pro cgroup geben mir Anteile, Wartezeiten und Staus, die auf Drosselung oder \u00dcberlast hindeuten. Mit <code>top<\/code>, <code>htop<\/code> und <code>systemd-cgtop<\/code> erkenne ich Verteilungstrends live und gleiche sie mit meinen Regeln ab. Wenn Latenzen hochgehen, aber CPU-Idle besteht, liegt das Problem eher an I\/O oder Locks statt an CPU-Limits; ich passe Gewichtung dann nicht \u00fcbereilt an. Nach \u00c4nderungen dokumentiere ich Messwerte \u00fcber mindestens einen Lastzyklus, damit ich falsche Korrelationen vermeide.<\/p>\n\n<h2>Monitoring-Playbook: Was ich konkret lese<\/h2>\n<ul>\n  <li><code>cpu.stat<\/code>: <em>usage_usec<\/em>, <em>user_usec<\/em>, <em>system_usec<\/em> zeigen Verbrauch; <em>nr_periods<\/em>, <em>nr_throttled<\/em>, <em>throttled_usec<\/em> entlarven harte Drosselung. Steigt <em>nr_throttled\/nr_periods<\/em> \u00fcber einige Prozent, ist die Quote zu eng oder die Periode zu kurz.<\/li>\n  <li><code>cpu.pressure<\/code>: Ich beobachte <em>some avg10\/60\/300<\/em> f\u00fcr latenzrelevante Staus. Ein dauerhaft erh\u00f6hter Wert trotz freier CPUs weist auf Lock-Contention, Affinit\u00e4tskonflikte oder NUMA-Fernzugriffe hin.<\/li>\n  <li><code>systemd-cgtop<\/code> und <code>ps<\/code>: Ich pr\u00fcfe, ob Threads wirklich parallel arbeiten k\u00f6nnen oder auf Exklusiv-Ressourcen warten.<\/li>\n<\/ul>\n<p>F\u00fcr reproduzierbare Tests setze ich <code>stress-ng<\/code>, <code>sysbench<\/code> oder eigene Lastgeneratoren ein und halte vorm\/nachher Metrik-Snapshots fest. Erst wenn Messwerte stabil den Erwartungen folgen, rolle ich \u00c4nderungen aus.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_cgroup_cpu_control_3281.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Echtzeit und Besonderheiten<\/h2>\n<p>Bei <strong>Echtzeit<\/strong>-Workloads beachte ich die Hinweise der Kernel-Dokumentation, da v2 den CPU-Controller f\u00fcr RT nur eingeschr\u00e4nkt f\u00fchrt. Bestimmte RT-Threads m\u00fcssen in der Root-cgroup liegen, und die Konfiguration verlangt vorsichtiges Vorgehen. Ich pr\u00fcfe au\u00dferdem, wie sich RT-Scheduling mit Quoten vertr\u00e4gt, damit keine Deadline unbeabsichtigt kippt. F\u00fcr typische Web- und Datenbankdienste nutze ich normale Policies, weil diese Konstellation im Alltag sicherer planbar bleibt. Wenn ich RT brauche, trenne ich Systeme oder reserviere Kerne klar, damit keine unerwarteten Wechselwirkungen eintreten [1].<\/p>\n\n<h2>Feinsteuerung auf Multi-Core-Systemen<\/h2>\n<p>Der CPU-Controller teilt <strong>Zeitfenster<\/strong>, nicht Taktrate, daher kombiniere ich ihn bei Bedarf mit cpuset und Affinit\u00e4t. F\u00fcr rauscharme Latenz kappe ich Cross-Socket-Wechsel, binde Threads an NUMA-lokale Kerne und optimiere IRQ-Verteilung. Batch-Services lasse ich flexibler laufen, damit sie Restkapazit\u00e4t einsammeln, ohne Kerne f\u00fcr kritische Frontends zu blockieren. Ich \u00fcberpr\u00fcfe Turbo- oder Powersave-Politiken, weil Frequenz\u00e4nderungen das Verhalten unter Last stark ver\u00e4ndern k\u00f6nnen. Erst die Summe aus Quoten, Gewichten, CPU-Affinit\u00e4t und Energie-Strategie liefert konsistente Ergebnisse.<\/p>\n\n<h2>SMT, NUMA und Affinit\u00e4t in der Praxis<\/h2>\n<p>Auf Systemen mit <strong>SMT\/Hyper-Threading<\/strong> beachte ich, dass zwei logische Threads auf einem physischen Kern nicht zwei volle CPU-Slots liefern. Eine Quote von \u201e100 %\u201c deckt einen logischen Slot ab, nicht zwingend eine volle physische Kernleistung. Ich messe deshalb Latenz und Throughput mit und ohne SMT-Nutzung. Bei NUMA-Systemen beschr\u00e4nke ich kritische Dienste mit <code>AllowedCPUs=<\/code> (cpuset) oder <code>CPUAffinity=<\/code> auf lokale Kerne und stelle Speicherbindung entsprechend ein, damit Remote-Zugriffe nicht jede Feinplanung zunichtemachen.<\/p>\n\n<h2>Best Practices f\u00fcr Hosting und Container<\/h2>\n<p>Ich starte mit moderaten <strong>Defaults<\/strong>: Webdienste leicht h\u00f6her gewichten, Datenbanken nahe Standard, Batch mit Quote. F\u00fcr Tenants setze ich Obergrenzen pro Kunde und erlaube Burst \u00fcber Gewichtung, solange kein anderer Bedarf besteht. Ich dokumentiere Profile nach Use-Case, etwa \u201elatenzkritisch\u201c, \u201egemischt\u201c und \u201erechenlastig\u201c, und lege pro Profil klare Spannweiten f\u00fcr weight und cpu.max fest. \u00c4nderungen spiele ich zuerst in Staging und mit synthetischer Last aus, die Spitzen realistisch abbildet. Logs und Metriken halte ich nah an den cgroup-Grenzen, damit Diagnosen nicht im Nebel enden.<\/p>\n\n<h2>Container-Orchestrierung: Shares, Requests und Limits<\/h2>\n<p>In Container-Umgebungen mappe ich <em>Requests<\/em> auf relative Gewichtung und <em>Limits<\/em> auf harte Quoten. Das erlaubt Burst, solange Knoten freie Kapazit\u00e4t haben, und sorgt unter Konkurrenz f\u00fcr faire Verteilung gem\u00e4\u00df Gewicht. Kritische Pods oder Services erhalten etwas mehr Gewicht, ohne dass Limits anderen die Luft nehmen. Ich achte darauf, dass die Summe der Limits pro Node realistisch zur vorhandenen CPU passt; sonst kommt es trotz sauberer Regeln zu systemweiter Drosselung, die alle Tenants trifft.<\/p>\n\n<h2>Beispiel-Konfigurationen und Rechenbeispiele<\/h2>\n<p>Ich rechne Quoten immer in <strong>Anteile<\/strong> pro vCPU-Slot um: <code>cpu.max = QUOTA PERIOD<\/code> entspricht <code>QUOTA\/PERIOD<\/code> des Slots. Beispiel: <code>20000 100000<\/code> sind 0,2 einer einzelnen CPU; auf vier CPUs ist das maximal 0,8 Gesamtslot, aber nicht garantiert verteilt. F\u00fcr Prozentangaben unter systemd schreibe ich <code>CPUQuota=20%<\/code>, was je nach Version mit cpu.max harmoniert. Wer harte Grenzen setzt, muss Burst-Verhalten gegen Latenz messen: Eine zu enge Periode kann Mikroruckler erzeugen, eine zu weite Periode verteilt glatter, reagiert aber tr\u00e4ger. Ich teste daher Perioden zwischen 50\u2013100 ms und w\u00e4hle die Variante, die zur Latenzklasse des Dienstes passt [2].<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-cgroup-cpu-8032.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Migration v1 \u2192 v2 ohne \u00dcberraschungen<\/h2>\n<p>Beim Umstieg \u00fcberf\u00fchre ich <code>cpu.shares<\/code> in <code>cpu.weight<\/code> und <code>cpu.cfs_quota_us\/period_us<\/code> in <code>cpu.max<\/code>. Ein pragmatisches Mapping f\u00fcr Shares ist: <em>1024 \u2192 ~100<\/em>, <em>2048 \u2192 ~200<\/em>, <em>512 \u2192 ~50<\/em>. Feinkorrekturen nehme ich nach Lasttests vor, denn die Skalen unterscheiden sich. Ich plane au\u00dferdem, dass v2-Regeln f\u00fcr Kinder <em>kumulativ<\/em> wirken: Eine drosselnde Quote am Elternknoten limitiert alle Untergruppen zusammen. Deshalb hebe ich Elternquoten oft auf (<code>max<\/code>) und reguliere granular in den Bl\u00e4ttern, damit ich Seiteneffekte vermeide.<\/p>\n\n<h2>H\u00e4ufige Fehlerbilder und Gegenma\u00dfnahmen<\/h2>\n<ul>\n  <li><strong>100 % verwechselt mit \u201ealle Kerne\u201c:<\/strong> 100 % entsprechen einem logischen CPU-Slot, nicht der gesamten Maschine. L\u00f6sung: Quote anhand ben\u00f6tigter Slots kalkulieren (z. B. 400 % f\u00fcr vier Slots).<\/li>\n  <li><strong>Zu enge Periode:<\/strong> Mikroruckler bei interaktiven Diensten. L\u00f6sung: Periode erh\u00f6hen oder Gewicht statt Quote nutzen.<\/li>\n  <li><strong>Gewichtung ohne Konkurrenz gemessen:<\/strong> Gewicht entfaltet Wirkung erst bei Wettbewerb. L\u00f6sung: Tests mit realer Parallel-Last fahren.<\/li>\n  <li><strong>Eltern-Quoten vergessen:<\/strong> Ein limitierter Parent drosselt alle Kinder. L\u00f6sung: <code>cpu.max=max<\/code> am Parent, Limits an den Bl\u00e4ttern.<\/li>\n  <li><strong>NUMA\/Sockel ignoriert:<\/strong> Latenz trotz freier CPU. L\u00f6sung: Affinit\u00e4t\/CPUSets und Speicherlokalit\u00e4t pr\u00fcfen.<\/li>\n<\/ul>\n\n<h2>Zusammenfassung<\/h2>\n<p>Mit dem <strong>CPU-Controller<\/strong> teile ich Rechenzeit gezielt zu, lege faire Priorit\u00e4ten fest und setze harte Grenzen dort, wo sie n\u00f6tig sind. cgroup v2 bringt dabei klare Parameter mit cpu.weight und cpu.max, die ich je nach Workload plane und messe. \u00dcber systemd setze ich Regeln pro Dienst, pr\u00fcfe die Wirkung mit cpu.stat und PSI und justiere ohne Ratespiel. F\u00fcr Tenants, Container und gemischte Serverlandschaften bleibt diese Steuerung ein Schl\u00fcssel, um Verl\u00e4sslichkeit und Vorhersagbarkeit zu erreichen. Wer Regeln dokumentiert, schrittweise einf\u00fchrt und mit Lasttests absichert, verhindert Engp\u00e4sse und beh\u00e4lt die Kontrolle \u00fcber die CPU-Zeit.<\/p>","protected":false},"excerpt":{"rendered":"<p>Controlador de CPU cgroup do Linux: pondera\u00e7\u00f5es, quotas e gest\u00e3o eficaz de recursos para servidores e ambientes de alojamento est\u00e1veis.<\/p>","protected":false},"author":1,"featured_media":21598,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21605","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"109","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"CPU Controller","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21598","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21605","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21605"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21605\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21598"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21605"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21605"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21605"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}