{"id":21395,"date":"2026-09-14T15:03:31","date_gmt":"2026-09-14T13:03:31","guid":{"rendered":"https:\/\/webhosting.de\/linux-psi-monitoring-grafana-visualisierung-ressourcendruck-ops\/"},"modified":"2026-09-14T15:03:31","modified_gmt":"2026-09-14T13:03:31","slug":"linux-psi-monitorowanie-grafana-wizualizacja-obciazenie-zasobow-ops","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/linux-psi-monitoring-grafana-visualisierung-ressourcendruck-ops\/","title":{"rendered":"Wizualizacja monitorowania PSI w systemie Linux za pomoc\u0105 Grafany: jak w\u0142a\u015bciwie zrozumie\u0107 i monitorowa\u0107 obci\u0105\u017cenie zasob\u00f3w"},"content":{"rendered":"<p>Ich zeige, wie ich <strong>linux psi<\/strong> mit Prometheus erfasse und in Grafana sichtbar mache, um Ressourcendruck auf CPU, Speicher und I\/O als echte Wartezeit zu messen. So erkenne ich <strong>Engp\u00e4sse<\/strong> fr\u00fch, ordne sie cgroups oder Containern zu und l\u00f6se bei Bedarf automatisierte Gegenma\u00dfnahmen aus.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<ul>\n  <li><strong>PSI-Metriken<\/strong>: some\/full f\u00fcr CPU, Memory, I\/O und gleitende Durchschnitte<\/li>\n  <li><strong>cgroup-Fokus<\/strong>: Container- und Service-spezifische Sicht statt nur global<\/li>\n  <li><strong>Alert-Trigger<\/strong>: Ereignisse bei Schwellwerten mit poll\/epoll nutzen<\/li>\n  <li><strong>Grafana<\/strong>: Panels f\u00fcr Trends, Peaks und Top-N-Verursacher<\/li>\n  <li><strong>Best Practices<\/strong>: Schwellen, Zeitfenster, Korrelation mit Systemmetriken<\/li>\n<\/ul>\n\n<h2>PSI kurz erkl\u00e4rt: Druck als reale Wartezeit verstehen<\/h2>\n\n<p>PSI beantwortet die Frage, wie viel <strong>Wallclock-Zeit<\/strong> Tasks vergeblich auf CPU, RAM oder I\/O warten. Die Dateien unter <code>\/proc\/pressure\/{cpu,memory,io,irq}<\/code> liefern zwei Perspektiven: <code>some<\/code> zeigt Phasen, in denen einige Tasks warten, <code>full<\/code> markiert Momente, in denen alle nicht-idlen Tasks blockieren. Ich bewerte beide Werte getrennt, weil <strong>some<\/strong> fr\u00fcher anschl\u00e4gt und <strong>full<\/strong> echte Stillst\u00e4nde sichtbar macht. Zus\u00e4tzlich nutze ich <code>avg10<\/code>, <code>avg60<\/code> und <code>avg300<\/code>, um kurzfristige Ausschl\u00e4ge und l\u00e4ngerfristige Trends zu unterscheiden. \u00dcber die wachsende <code>total<\/code>-Zeit erkenne ich, wie stark sich Druck seit dem Boot summiert und wo <strong>Hotspots<\/strong> liegen.<\/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\/linux-psi-monitoring-grafana-8472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systemweite vs. cgroup-PSI: Die richtige Ebene w\u00e4hlen<\/h2>\n\n<p>Ich unterscheide bewusst zwischen globalen Druckwerten und der Sicht pro <strong>cgroup<\/strong>. Die Dateien unter <code>\/proc\/pressure\/<\/code> zeigen das System als Ganzes, w\u00e4hrend cgroup v2 zus\u00e4tzlich <code>cpu.pressure<\/code>, <code>memory.pressure<\/code> und <code>io.pressure<\/code> je Gruppe anbietet. In Container-Umgebungen ordne ich damit Druck sauber Pods, Services oder <strong>Containern<\/strong> zu. Diese Zuordnung verhindert Blindfl\u00fcge: Statt r\u00e4tselraten zu m\u00fcssen, sehe ich den Verursacher direkt in der Gruppe. Auf Multi\u2011Tenant-Hosts trenne ich so Shared- und dedizierte Lasten und steuere <strong>Limits<\/strong> gezielt.<\/p>\n\n<h2>Voraussetzungen pr\u00fcfen: Kernel, PSI und cgroup v2 aktivieren<\/h2>\n\n<p>Bevor ich Metriken sammle, stelle ich sicher, dass die Plattform passt:<\/p>\n<ul>\n  <li><strong>Kernel-Version<\/strong>: PSI ist ab Linux 4.20 verf\u00fcgbar. Ich pr\u00fcfe mit <code>uname -r<\/code> und kontrolliere via <code>zcat \/proc\/config.gz | grep CONFIG_PSI<\/code>, ob der Support einkompiliert ist.<\/li>\n  <li><strong>PSI-Laufzeit-Flag<\/strong>: Einige Distributionen erlauben das optionale Boot-Flag <code>psi=1<\/code>, um PSI vollst\u00e4ndig zu aktivieren. Ich setze es bei Bedarf und verifiziere, dass <code>\/proc\/pressure\/*<\/code> Inhalte liefert.<\/li>\n  <li><strong>cgroup v2<\/strong>: F\u00fcr per\u2011Service\/Container\u2011Sicht nutze ich die <em>unified hierarchy<\/em>. Ich pr\u00fcfe mit <code>mount | grep cgroup2<\/code> und erwarte einen <code>cgroup2<\/code>-Mount (oft <code>\/sys\/fs\/cgroup<\/code>). Fehlt er, aktiviere ich ihn \u00fcber den Kernel-Parameter <code>systemd.unified_cgroup_hierarchy=1<\/code> (Neustart erforderlich).<\/li>\n  <li><strong>Berechtigungen<\/strong>: Exporter auf dem Host brauchen Leserechte auf <code>\/proc\/pressure\/*<\/code> und ggf. auf <code>\/sys\/fs\/cgroup\/*\/*.pressure<\/code>. In Containern mounte ich diese Pfade read\u2011only ein.<\/li>\n<\/ul>\n\n<h2>PSI-Trigger nutzen: Automatisch reagieren statt nur beobachten<\/h2>\n\n<p>Neben Zeitreihen stelle ich auch Ereignisse \u00fcber <strong>poll<\/strong> oder <strong>epoll<\/strong> ein, indem ich Schwellwerte und Zeitfenster in die PSI-Dateien schreibe. Sobald der Ressourcendruck den Grenzwert im Fenster \u00fcbersteigt, feuert ein Event und ich starte Gegenma\u00dfnahmen. Das kann ein zus\u00e4tzlicher Pod, ein Cache-Flush oder die tempor\u00e4re Drosselung eines <strong>Batch-Jobs<\/strong> sein. In Systemd-Units binde ich diese Reaktion direkt an Services und halte Latenzen flach. So wird Monitoring zur Steuerung, nicht blo\u00df zur <strong>Anzeige<\/strong>.<\/p>\n\n<p>In der Praxis setze ich ein kompaktes Watcher\u2011Programm ein, das die entsprechenden <code>*pressure<\/code>-Dateien \u00f6ffnet, per <code>write()<\/code> einen Trigger (<code>some<\/code> oder <code>full<\/code> samt Schwellwert und Fenster in \u00b5s) registriert und anschlie\u00dfend mit <code>epoll<\/code> blockierend auf Ereignisse wartet. So spare ich Poll\u2011Zyklen und reagiere deterministisch. Ich halte die Fenster bewusst etwas l\u00e4nger (z. B. 10\u201330 s), um Transienten auszublenden, und unterscheide je Ressource: <em>memory<\/em> reagiert empfindlicher als <em>io<\/em>, <em>cpu<\/em> muss deutlicher sein, um zu feuern.<\/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\/linuxpsi_grafana_meeting_4123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>PSI nach Prometheus exportieren: Agenten, Metriken, Labels<\/h2>\n\n<p>F\u00fcr die Zeitreihen sammle ich PSI \u00fcber einen dedizierten Exporter oder integriere die Werte in bestehende Agenten wie den <strong>Node-Exporter<\/strong>. Entscheidend sind konsistente Labels f\u00fcr Host, cgroup und Container, damit Queries in Grafana sauber filtern. In Kubernetes verwende ich zus\u00e4tzlich cAdvisor- und Kubelet-Metriken f\u00fcr <code>*_pressure_*_waiting_seconds_total<\/code>, damit Knoten-, Pod- und Container-Ebenen deckungsgleich bleiben. F\u00fcr klassische Hosts lese ich <code>\/proc\/pressure\/*<\/code> direkt und mappe <strong>some<\/strong> und <strong>full<\/strong> auf separate Metrik-Namen. Eine Anleitung zur Agenten-Integration hilft beim Start, etwa unter <a href=\"https:\/\/webhosting.de\/node-exporter-konfiguration-prometheus-linux-monitoring-metriken\/\">Node Exporter einrichten<\/a>.<\/p>\n\n<h2>Exporter-Varianten im Detail: Node, cgroup und Kubernetes<\/h2>\n\n<p>Ich setze je nach Umgebung unterschiedliche Wege ein:<\/p>\n<ul>\n  <li><strong>Node-Exporter<\/strong> (Host-Ebene): Ich aktiviere den <em>pressure<\/em>-Collector (falls nicht per Default aktiv) z.\u202fB. \u00fcber <code>--collector.pressure<\/code>. Er liefert Metriken wie <code>node_pressure_cpu_some_avg10<\/code>, <code>node_pressure_memory_full_avg60<\/code> sowie <code>node_pressure_io_waiting_seconds_total{state=\"some|full\"}<\/code>. Letztere eignen sich f\u00fcr <code>rate()<\/code>-Analysen und Top\u2011N.<\/li>\n  <li><strong>Eigener cgroup-Exporter<\/strong> (Service\/Container-Ebene): F\u00fcr feingranulare Sicht lese ich <code>\/sys\/fs\/cgroup\/&lt;gruppe&gt;\/{cpu,memory,io}.pressure<\/code> und emittiere Metriken wie <code>cgroup_pressure_memory_waiting_seconds_total{state=\"full\",cgroup=\"...\"} <\/code> sowie die <code>avg10\/60\/300<\/code>\u2011Gauges. Ich normalisiere den cgroup\u2011Pfad als Label (<code>cgroup<\/code>) oder mappe auf <code>service<\/code>\/<code>container<\/code> Labels.<\/li>\n  <li><strong>Kubernetes<\/strong>: Auf Knotenebene scrapt Prometheus <em>node\u2011exporter<\/em>. F\u00fcr Container\u2011Sicht nutze ich einen DaemonSet\u2011Exporter mit <code>hostPID:true<\/code> und Read\u2011Only\u2011Mounts von <code>\/sys\/fs\/cgroup<\/code> und <code>\/proc<\/code>, damit ich die cgroup\u2011Dateien des Hosts sehe. Zus\u00e4tzlich ziehe ich Kubelet\/cAdvisor\u2011Metriken heran, sofern sie die PSI\u2011Totals ausgeben; die Labels <code>namespace<\/code>, <code>pod<\/code> und <code>container<\/code> halte ich dabei konsistent.<\/li>\n<\/ul>\n\n<p>Mir hilft eine klare <strong>Label-Strategie<\/strong>: <code>instance<\/code> (Host oder NodeName), <code>cgroup<\/code> (Pfad), <code>namespace<\/code>\/<code>pod<\/code>\/<code>container<\/code> (bei K8s) sowie <code>state<\/code> (<code>some<\/code>\/<code>full<\/code>) und <code>resource<\/code> (<code>cpu<\/code>\/<code>memory<\/code>\/<code>io<\/code>\/<code>irq<\/code>). So kann ich stark aggregieren und zugleich tief zoomen.<\/p>\n\n<h2>Prometheus-Jobs, Recording Rules und Beispiel-Queries<\/h2>\n\n<p>F\u00fcr saubere Auswertungen nutze ich zwei Muster: Prozent\u2011Gauges (<code>avg10\/60\/300<\/code>) und abgeleitete <code>rate()<\/code>\u2011Werte auf den <code>*_waiting_seconds_total<\/code>\u2011Z\u00e4hlern.<\/p>\n<ul>\n  <li><strong>Scrape<\/strong>: 15s ist ein guter Start. K\u00fcrzer erh\u00f6ht Last, bringt bei <code>avg10<\/code> aber selten Mehrwert.<\/li>\n  <li><strong>Recording Rules<\/strong>: Ich berechne abgeleitete Zeitreihen, um Dashboards und Alerts zu vereinfachen:\n    <ul>\n      <li><code>record: psi:node_memory_full:avg60 = avg_over_time(node_pressure_memory_full_avg10[60s])<\/code><\/li>\n      <li><code>record: psi:node_io_full:rate5m = rate(node_pressure_io_waiting_seconds_total{state=\"full\"}[5m])<\/code><\/li>\n      <li><code>record: psi:cgroup_memory_full:rate5m = sum by (cgroup) (rate(cgroup_pressure_memory_waiting_seconds_total{state=\"full\"}[5m]))<\/code><\/li>\n    <\/ul>\n  <\/li>\n<\/ul>\n\n<p>Mit PromQL baue ich typische Sichten:<\/p>\n<ul>\n  <li><strong>Host\u2011Trend<\/strong>: <code>node_pressure_memory_full_avg60<\/code> \u00fcber Zeit, getrennt nach Knoten.<\/li>\n  <li><strong>Top\u2011N\u2011Verursacher<\/strong>: <code>topk(5, psi:cgroup_memory_full:rate5m)<\/code> zeigt die lautesten cgroups.<\/li>\n  <li><strong>Impact auf Latenz<\/strong>: <code>(increase(http_request_duration_seconds_sum[5m]) \/ increase(http_request_duration_seconds_count[5m]))<\/code> gegen <code>node_pressure_io_full_avg60<\/code> legen, um Korrelationen zu erkennen.<\/li>\n  <li><strong>Plateaus erkennen<\/strong>: <code>clamp_min(psi:node_io_full:rate5m, 0.0)<\/code> als Heatmap pro Knoten.<\/li>\n<\/ul>\n\n<h2>Grafana-Dashboards: Trends sichtbar machen und Hotspots finden<\/h2>\n\n<p>In Grafana zeige ich CPU-, Memory- und I\/O-Druck getrennt an, jeweils f\u00fcr <strong>some<\/strong> und <strong>full<\/strong> als eigene Kurven. Bar-Gauges liefern mir den aktuellen Status, w\u00e4hrend Timeseries-Panels Peaks und Plateaus enth\u00fcllen. F\u00fcr Ursachenanalyse setze ich Top\u2011N\u2011Ansichten nach cgroup, Container oder Pod ein und springe von dort in Detail-Panels. Wichtig bleibt die Kombination aus <code>avg10<\/code>, <code>avg60<\/code> und <code>avg300<\/code>, um \u00dcbersteuerungen durch kurze Spikes zu vermeiden. Wer Dashboards vordenken will, findet hilfreiche Ideen rund um den <a href=\"https:\/\/webhosting.de\/grafana-prometheus-hosting-monitoring-stack-dashboard-serverwatch-enhance\/\">Grafana und Prometheus<\/a> Stack.<\/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-psi-grafana-monitoring-8473.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Alarmierung in der Praxis: Regeln, Fenster, Eskalation<\/h2>\n\n<p>Ich halte mich an ein zweistufiges Modell: <em>Warnung<\/em> f\u00fcr fr\u00fche Signale, <em>Kritisch<\/em> f\u00fcr dauerhaften Engpass. Beispielhaft setze ich:<\/p>\n<ul>\n  <li><strong>Memory<\/strong>\n    <ul>\n      <li>Warnung: <code>node_pressure_memory_full_avg60 &gt; 0.01<\/code> f\u00fcr 10\u201330 s<\/li>\n      <li>Kritisch: <code>node_pressure_memory_full_avg60 &gt; 0.05<\/code> f\u00fcr \u226560 s<\/li>\n    <\/ul>\n  <\/li>\n  <li><strong>I\/O<\/strong>\n    <ul>\n      <li>Warnung: <code>rate(node_pressure_io_waiting_seconds_total{state=\"some\"}[5m]) &gt; 0.02<\/code><\/li>\n      <li>Kritisch: <code>node_pressure_io_full_avg60 &gt; 0.02<\/code> f\u00fcr \u2265120 s<\/li>\n    <\/ul>\n  <\/li>\n  <li><strong>CPU<\/strong>\n    <ul>\n      <li>Warnung: <code>node_pressure_cpu_some_avg60 &gt; 0.05<\/code><\/li>\n      <li>Kritisch: <code>node_pressure_cpu_full_avg60 &gt; 0.01<\/code> (weil <em>full<\/em> hier besonders weh tut)<\/li>\n    <\/ul>\n  <\/li>\n<\/ul>\n<p>In Annotations verkn\u00fcpfe ich Kontexte (Top\u2011cgroups, Durchsatz, Latenz) und starte Playbooks: Scale\u2011Up, Limits anpassen, Cache\u2011Aktionen, Batch\u2011Drosselung. Bei wiederholten Events ziehe ich Kapazit\u00e4tsentscheidungen vor.<\/p>\n\n<h2>Schwellen und Alarmierung: Zeitfenster richtig w\u00e4hlen<\/h2>\n\n<p>Ich definiere klare Schwellwerte pro Ressource und trenne harte Ausf\u00e4lle von kurzen Lastspitzen. Beispielsweise werte ich <strong>memory full<\/strong> \u00fcber 5 % l\u00e4nger als 60 Sekunden als kritisch, w\u00e4hrend 1\u20132 % \u00fcber zehn Sekunden nur eine Warnung ausl\u00f6sen. F\u00fcr CPU setze ich strengere Grenzen auf <strong>full<\/strong>, da fl\u00e4chendeckendes Warten dort sp\u00fcrbar bremst. Mehrwert bringt die Kopplung mit Durchsatz- und Latenzmetriken: Wenn Druck steigt und Requests langsamer werden, erh\u00f6ht sich die Dringlichkeit. Ich lege Alerts stets auf Zeitfenster, nicht auf Einzelwerte, um Fehlalarme durch <strong>Bursts<\/strong> zu vermeiden.<\/p>\n\n<h2>Kubernetes: Scrape-Setup, Rechte und Korrelation<\/h2>\n\n<p>Im Cluster sammele ich PSI so, dass die Ebenen deckungsgleich werden:<\/p>\n<ul>\n  <li><strong>Node-Exporter als DaemonSet<\/strong>: Standard\u2011Scrape pro Node liefert globale PSI\u2011Werte.<\/li>\n  <li><strong>cgroup\u2011Exporter als Sidecar\/DaemonSet<\/strong>: Liest die cgroup v2\u2011Dateien des Hosts, labelt nach <code>namespace\/pod\/container<\/code>. Ich nutze minimal n\u00f6tige Rechte und RO\u2011Mounts.<\/li>\n  <li><strong>Kubelet\/cAdvisor<\/strong>: Ich aktiviere die Ausgabe relevanter Container\u2011Metriken und scrappe den Kubelet\u2011Endpunkt. Ich halte die Label\u2011Join\u2011Keys (z.\u202fB. <code>container<\/code> vs. <code>container_name<\/code>) konsistent, damit PromQL\u2011Joins ohne Friktion funktionieren.<\/li>\n  <li><strong>Join mit Workload-Metriken<\/strong>: Ich korreliere Pod\u2011PSI mit App\u2011Latenzen (z.\u202fB. HTTP\u2011Metriken), CPU\u2011Limits\u2011Hits und Speicherfehlern. So erkenne ich, ob Limits, Scheduling oder Storage\u2011Bottlenecks die Ursache sind.<\/li>\n<\/ul>\n\n<h2>PSI-Dateien, Kennzahlen und Lesart: Kompakte \u00dcbersicht<\/h2>\n\n<p>Die folgende Tabelle fasst die wichtigsten Dateien, Kennzahlen und Einsatzzwecke zusammen, damit ich schneller interpretiere und passende Grafana-Panels baue. Ich nutze sie bei der Analyse, um die n\u00e4chste Frage zu planen: Tuning, Skalierung oder Entst\u00f6rung. Besonders relevant bleiben die Unterschiede zwischen <strong>some<\/strong> und <strong>full<\/strong> sowie die drei Durchschnittsfenster. So ordne ich Symptome zeitlich ein und pr\u00fcfe, ob der Druck lokal oder fl\u00e4chig auftritt. Die Spalte \u201eEinsatz\u201c hilft bei der schnellen <strong>Einordnung<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Ressource<\/th>\n      <th>Datei<\/th>\n      <th>Kennzahlen<\/th>\n      <th>Bedeutung<\/th>\n      <th>Einsatz<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>CPU<\/strong><\/td>\n      <td><code>\/proc\/pressure\/cpu<\/code><\/td>\n      <td>some, full; avg10\/60\/300; total<\/td>\n      <td>Wartezeit auf freie Rechenzeit<\/td>\n      <td>\u00dcberlastete Hosts, zu enge CPU-<strong>Limits<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Memory<\/strong><\/td>\n      <td><code>\/proc\/pressure\/memory<\/code><\/td>\n      <td>some, full; avg10\/60\/300; total<\/td>\n      <td>Wartezeit durch Reclaim, Swap, OOM-N\u00e4he<\/td>\n      <td>RAM-Engp\u00e4sse, Cache\u2011Druck, fehlerhafte <strong>Requests<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td><strong>I\/O<\/strong><\/td>\n      <td><code>\/proc\/pressure\/io<\/code><\/td>\n      <td>some, full; avg10\/60\/300; total<\/td>\n      <td>Wartezeit auf Speicherger\u00e4te\/Dateisystem<\/td>\n      <td>Langsame Datentr\u00e4ger, Sync-St\u00fcrme, <strong>Flush<\/strong>-Phasen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>IRQ<\/strong><\/td>\n      <td><code>\/proc\/pressure\/irq<\/code><\/td>\n      <td>some, full; avg10\/60\/300; total<\/td>\n      <td>Druck durch Interrupt-Bearbeitung<\/td>\n      <td>Netzwerk-Last, Treiber-Tuning, <strong>Affinity<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td><strong>cgroup<\/strong><\/td>\n      <td><code>*\/{cpu,memory,io}.pressure<\/code><\/td>\n      <td>some, full; avg10\/60\/300; total<\/td>\n      <td>Druck je Service\/Container<\/td>\n      <td>Root-Cause\u2011Suche, gezielte <strong>Limits<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/linuxgrafana9742.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praxis: Hosting und WordPress-Stacks effizient absichern<\/h2>\n\n<p>Auf stark genutzten WordPress-Hosts konkurrieren PHP\u2011FPM, Datenbank und Cache\u2011Layer regelm\u00e4\u00dfig um RAM und I\/O, was ich \u00fcber <strong>memory<\/strong> und <strong>io<\/strong> sofort sehe. Steigt <code>full<\/code> bei Memory, optimiere ich OpCache, erh\u00f6he Pool\u2011Gr\u00f6\u00dfen dosiert oder reduziere teure Plugins. Bei I\/O\u2011Druck pr\u00fcfe ich Query-Pl\u00e4ne, Journaling\u2011Einstellungen und asynchrones Schreiben. PSI pro cgroup macht sichtbar, ob Webserver, Worker oder Datenbank den Engpass verursachen. Wer tiefer einsteigen will, findet Hinweise im <a href=\"https:\/\/webhosting.de\/linux-psi-pressure-stall-information-performanceanalyse-serverdruck\/\">Linux-PSI Ratgeber<\/a>, der Einstieg und Bewertung zusammenfasst.<\/p>\n\n<h2>Kapazit\u00e4tsplanung und Tuning: Von Zahlen zu Aktionen<\/h2>\n\n<p>Ich verbinde PSI mit CPU\u2011Auslastung, Page\u2011Faults, I\/O\u2011Durchsatz und Latenzen, um echte Ursachen zu erkennen. Bei anhaltendem <strong>memory full<\/strong> skaliere ich RAM, optimiere Reclaim\u2011Parameter oder ziehe Workloads auseinander. Zeigt <strong>io full<\/strong> lange Plateaus, erh\u00f6he ich Queue\u2011Tiefen, aktiviere Write\u2011Back\u2011Strategien oder setze schnellere Datentr\u00e4ger ein. F\u00fcr CPU\u2011Druck messe ich Runqueue\u2011L\u00e4ngen parallel, passe Scheduling\u2011Klassen an und verteile hei\u00dfe Threads. Entscheidungen treffe ich nur, wenn Trends im <code>avg60<\/code> und <code>avg300<\/code> konsistent bleiben und nicht nur ein <strong>Spike<\/strong> vorliegt.<\/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\/linuxgrafanamonitoring4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Troubleshooting und Validierung: Vom Host bis zum Container<\/h2>\n\n<p>Bei fehlenden PSI-Werten pr\u00fcfe ich Kernel-Version, <strong>CONFIG_PSI<\/strong> und optional den Boot\u2011Parameter <code>psi=1<\/code>. Anschlie\u00dfend verifiziere ich die Ausgaben der Dateien unter <code>\/proc\/pressure\/*<\/code> manuell und gleiche sie mit Exporter-Metriken ab. In cgroup v2 kontrolliere ich zus\u00e4tzlich die <code>*.pressure<\/code>-Dateien innerhalb der Gruppenverzeichnisse. Ich teste Alerts mit Lastgeneratoren und beobachte Reaktionslogik via <strong>epoll<\/strong>, um Fehlkonfigurationen fr\u00fch zu entdecken. Abschlie\u00dfend gleiche ich Grafana-Panels mit Logs, Traces und Profilergebnissen ab, damit Diagnose und Gegenma\u00dfnahme sicher <strong>passen<\/strong>.<\/p>\n\n<p>Typische Stolpersteine, die ich einkalkuliere:<\/p>\n<ul>\n  <li><strong>Swap-Interaktion<\/strong>: Leichte <em>memory some<\/em>-Werte sind normal bei aggressivem Reclaim. Kritisch wird es, wenn <em>full<\/em> steigt und gleichzeitig Latenzen anziehen.<\/li>\n  <li><strong>CPU-Isolation und Affinity<\/strong>: Pinned\/isolierte Kerne k\u00f6nnen lokal <em>cpu full<\/em> erzeugen, obwohl der Host gesamt noch Luft hat. Ich pr\u00fcfe <em>irq<\/em>-PSI zus\u00e4tzlich, wenn Netzwerk\/Storage stark interruptlastig ist.<\/li>\n  <li><strong>Virtuelle Umgebungen<\/strong>: In VMs spiegeln PSI\u2011Werte auch Hypervisor\u2011Einfl\u00fcsse. Ich messe Host\u2011 und Gast\u2011Ebene getrennt, um Overcommitment eindeutig zuzuordnen.<\/li>\n  <li><strong>Scrape-Overhead<\/strong>: PSI selbst ist g\u00fcnstig, aber zu kurze Scrape\u2011Intervalle erh\u00f6hen Prometheus\u2011Last. 15 s ist oft der Sweet\u2011Spot.<\/li>\n  <li><strong>Label-Kardinalit\u00e4t<\/strong>: cgroup\u2011Pfade k\u00f6nnen explodieren. Ich reguliere mit <em>labeldrop<\/em>\/<em>keep<\/em> und mappe nur die Ebenen, die ich analysiere (z.\u202fB. Service statt jeder kurzlebigen Task\u2011cgroup).<\/li>\n<\/ul>\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\/grafana-monitoring-linux-4850.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p>PSI misst echte <strong>Wartezeit<\/strong> auf CPU, RAM und I\/O und liefert damit ein klares Signal f\u00fcr Ressourcendruck. Mit Prometheus-Export und Grafana-Dashboards baue ich eine Sicht, die Ursachen trennt und Hotspots schnell aufdeckt. Die Trennung von <strong>some<\/strong> und <strong>full<\/strong> plus die Fenster <code>avg10\/60\/300<\/code> macht Entscheidungen belastbar. Alerts ziele ich auf Zeitr\u00e4ume, verkn\u00fcpfe sie mit Latenzen und steuere automatische Reaktionen \u00fcber Trigger. So treffe ich fundierte Kapazit\u00e4tsentscheide, entsch\u00e4rfe Engp\u00e4sse rechtzeitig und halte Dienste im Alltag <strong>reaktionsschnell<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, jak wizualizowa\u0107 dane dotycz\u0105ce przeci\u0105\u017cenia (pressure stall) za pomoc\u0105 narz\u0119dzia linux psi i Grafany, precyzyjnie mierzy\u0107 obci\u0105\u017cenie zasob\u00f3w oraz optymalizowa\u0107 \u015brodowiska hostingowe.<\/p>","protected":false},"author":1,"featured_media":21388,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-21395","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"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":"86","_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":"linux psi","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":"21388","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21395","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=21395"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21395\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/21388"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=21395"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=21395"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=21395"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}