{"id":20204,"date":"2026-07-31T18:20:33","date_gmt":"2026-07-31T16:20:33","guid":{"rendered":"https:\/\/webhosting.de\/oom-killer-linux-speicher-out-of-memory-analyse-hosting\/"},"modified":"2026-07-31T18:20:33","modified_gmt":"2026-07-31T16:20:33","slug":"oom-killer-linux-memoria-falta-de-memoria-analisis-alojamiento-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/oom-killer-linux-speicher-out-of-memory-analyse-hosting\/","title":{"rendered":"Entender el OOM Killer: cuando Linux termina procesos"},"content":{"rendered":"<p>Der Beitrag erkl\u00e4rt, wie der <strong>oom killer linux<\/strong> bei akuten Engp\u00e4ssen im Arbeitsspeicher eingreift und warum er Dienste hart beendet, um den Server betriebsbereit zu halten. Ich zeige Schritt f\u00fcr Schritt, wie ich Ausl\u00f6ser erkenne, das Scoring verstehe und mit gezielten Einstellungen das Verhalten unter Speicherdruck steuere.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<ul>\n  <li><strong>Ausl\u00f6ser<\/strong>: OOM-Events entstehen bei vollem RAM, ersch\u00f6pftem Swap und erfolglosen Reclaim-Versuchen.<\/li>\n  <li><strong>Scoring<\/strong>: Der Kernel vergibt einen <code>oom_score<\/code> und t\u00f6tet Prozesse mit hohem Anteil am Speicher.<\/li>\n  <li><strong>Erkennung<\/strong>: Hinweise finden sich in <code>dmesg<\/code> mit \u201eOut of memory\u201c und \u201eKilled process\u201c.<\/li>\n  <li><strong>Steuerung<\/strong>: Mit <code>oom_score_adj<\/code> priorisiere ich Dienste gezielt nach Wichtigkeit.<\/li>\n  <li><strong>Pr\u00e4vention<\/strong>: Monitoring, Limits, Swap-Strategie und Leak-Analyse verhindern harte Kills.<\/li>\n<\/ul>\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\/07\/oom-killer-linux-prozess-3948.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Was ist der OOM Killer im Linux\u2011Kernel?<\/h2>\n\n<p>Der OOM Killer ist die letzte <strong>Sicherheitslinie<\/strong> des Kernels und beendet Prozesse, wenn keine Speicherseiten mehr bereitstehen. Ich sehe ihn als kontrollierten Not-Aus, der einen Totalausfall verhindert und sofort RAM freischaufelt. Vorher versucht das System, Seiten zu swappen oder Caches zu leeren, doch bei anhaltendem Druck bleibt nur noch der harte Schnitt. In Logs erkenne ich diesen Moment an Eintr\u00e4gen mit \u201eOut of memory\u201c und \u201eKilled process\u201c, h\u00e4ufig begleitet von einem SIGKILL. Das Verhalten ist standardm\u00e4\u00dfig aktiv und l\u00e4uft automatisch, was in produktiven Umgebungen oft f\u00fcr \u00dcberraschungen sorgt, wenn wichtige Dienste ohne Vorwarnung verschwinden.<\/p>\n\n<h2>Wann greift der Mechanismus ein?<\/h2>\n\n<p>OOM-Events treten auf, wenn physischer RAM fast vollst\u00e4ndig belegt ist, der Swap keinen Puffer mehr liefert und Anfragen auf neue Seiten fehlschlagen. In dieser Situation bewertet der Kernel, ob Reclaim aus dem <strong>Page\u2011Cache<\/strong> und Swapping noch hilft, und startet erst bei Aussichtslosigkeit den Killer. Kurzfristige Peaks l\u00f6sen den Mechanismus nicht direkt aus; es braucht anhaltenden Druck und vergebliche Freigabeversuche. F\u00fcr die Analyse hilft mir ein Blick auf RSS, Swap-Usage, Page-Cache-Anteil und die Zuteilungen pro Control Group. Wer tiefer verstehen will, wie Cache-Verdr\u00e4ngung wirkt, kann sich die Hintergr\u00fcnde zu <a href=\"https:\/\/webhosting.de\/server-page-cache-eviction-linux-memory-druck-optimierung-insight\/\">Page Cache Eviction<\/a> ansehen und die Effekte im eigenen System messen.<\/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\/07\/besprechung_linux_oom_killer_3517.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wie w\u00e4hlt der Kernel das \u201eOpfer\u201c aus?<\/h2>\n\n<p>Die Auswahl folgt einem <strong>Scoring<\/strong>, das Linux als <code>oom_score<\/code> je Prozess berechnet. Ein hoher Anteil am Gesamtspeicher, viel RSS und unkritische Rolle f\u00fchren zu einem gr\u00f6\u00dferen Score. Systemnahe Prozesse wie init erhalten einen Rabatt, w\u00e4hrend speicherhungrige Worker oder Caches h\u00e4ufig vorn liegen. \u00dcber <code>oom_score_adj<\/code> kann ich den Score gezielt verschieben und damit die Opferkette steuern. Typischerweise beendet der Kernel den Prozess mit dem h\u00f6chsten Score per SIGKILL, um mit einem Schlag m\u00f6glichst viel RAM freizugeben.<\/p>\n\n<h2>Spuren erkennen: Logs und Signale<\/h2>\n\n<p>Nach einem pl\u00f6tzlichen Dienstende pr\u00fcfe ich zuerst <strong>dmesg<\/strong> und die Kernel-Logs. Tauchen dort \u201eOut of memory\u201c und \u201eKilled process\u201c auf, notiere ich PID, Prozessnamen, Benutzer und den berechneten Score. H\u00e4ufig fehlt in der Applikation selbst ein Fehlerlog, weil SIGKILL keine Aufr\u00e4umphase erlaubt. Ich gleiche den Zeitpunkt mit dem Monitoring ab, um den Anstieg von RAM, Swap und RSS pro Prozess nachzuvollziehen. So identifiziere ich Leaks, zu gro\u00dfe Heaps oder fehlende Limits zuverl\u00e4ssig und z\u00fcgig.<\/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\/07\/oom-killer-linux-processes-9021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kontrolle gewinnen mit oom_score und oom_score_adj<\/h2>\n\n<p>Jeder Prozess besitzt in <code>\/proc\/[PID]\/oom_score<\/code> einen aktuellen <strong>Wert<\/strong> f\u00fcr seine Gef\u00e4hrdungslage. Mit <code>\/proc\/[PID]\/oom_score_adj<\/code> senke oder erh\u00f6he ich die Wahrscheinlichkeit, dass der Kernel diesen Prozess beendet. Kritische Dienste wie Datenbanken sch\u00fctze ich mit einem negativen Adj, unwichtige Worker mache ich \u201eopferbar\u201c mit einem positiven Adj. Die \u00c4nderung wirkt sofort, was gerade bei Rollouts oder Lasttests n\u00fctzlich ist. So forme ich aus einem unberechenbaren Notmechanismus ein Werkzeug, das meiner Priorit\u00e4t folgt.<\/p>\n\n<h2>Typische Hosting-Szenarien unter Speicherdruck<\/h2>\n\n<p>In Umgebungen mit vielen Containern, Datenbanken und Caches sehe ich den OOM Killer besonders oft. Eine Datenbank, die unkontrolliert w\u00e4chst, verdr\u00e4ngt andere Dienste aus dem <strong>RAM<\/strong> und f\u00fchrt zu harten Kills. Memory Leaks in Webanwendungen bauen \u00fcber Stunden Druck auf, bis kein Reclaim mehr hilft. Zu gro\u00dfz\u00fcgige Container-Limits auf einem zu kleinen Host versch\u00e4rfen die Lage zus\u00e4tzlich. Wer diese Muster kennt, setzt fr\u00fchzeitig Alarme und greift ein, bevor der Killer das Heft \u00fcbernimmt.<\/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\/07\/oom_killer_techoffice_9123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Best Practices zur Vermeidung harter Kills<\/h2>\n\n<p>Ich plane Speicher realistisch, gebe Puffer f\u00fcr Spitzenlast ein und setze klare Limits pro Dienst. Monitoring erfasst pro Prozess RSS, Swap-Usage und <strong>oom_score<\/strong>, damit Warnungen vor dem Ernstfall feuern. In Container-Setups setze ich Cgroup-Grenzen, damit einzelne Services den Host nicht dominieren. Eine sinnvolle Swap-Strategie f\u00e4ngt Peaks ab, ohne das System dauerhaft zu verlangsamen. F\u00fcr tieferes Verst\u00e4ndnis und Planung helfe ich mir mit Praxisleitf\u00e4den zu <a href=\"https:\/\/webhosting.de\/virtual-memory-server-management-hosting-speicher\/\">virtuellen Speicher managen<\/a>, damit Workloads verl\u00e4sslich Luft haben.<\/p>\n\n<h2>Strukturierter Ablauf bei einem OOM-Vorfall<\/h2>\n\n<p>Nach dem Vorfall sichere ich zuerst Logzeilen aus <strong>dmesg<\/strong> und kern.log und ordne sie zeitlich ein. Im Monitoring pr\u00fcfe ich die Kurven f\u00fcr RAM, Swap, RSS und Page-Cache, um den Druckverlauf zu sehen. Danach checke ich ulimits, Cgroup- und Container-Limits sowie Applikations-Parameter wie Heaps von JVMs. Anschlie\u00dfend passe ich <code>oom_score_adj<\/code> an, damit Wichtigeres bleibt und Entbehrliches zuerst geht. Zuletzt behebe ich die Ursache: Leaks fixen, Caches begrenzen, Parallelit\u00e4t reduzieren und Kapazit\u00e4ten korrekt dimensionieren.<\/p>\n\n<h2>Besonderheiten in VPS- und Cloud-Umgebungen<\/h2>\n\n<p>Auf virtuellen Maschinen kommt eine zweite Ebene an Limits hinzu, etwa durch den Hypervisor oder die Orchestrierung. Ich kenne daher die zugeteilte <strong>RAM<\/strong>-Menge exakt und setze Kubernetes- oder Container-Limits passend. Der Linux OOM Killer arbeitet weiterhin wie beschrieben, doch Provider-Mechanismen k\u00f6nnen zus\u00e4tzliche Drosselungen ausl\u00f6sen. Gerade bei vielen Pods hilft eine klare Priorisierung: Wichtige Deployments erhalten Reserven, unkritische Jobs laufen enger. Dokumentation des Plattformanbieters und eigene Tests verhindern \u00dcberraschungen im Produktivbetrieb.<\/p>\n\n<h2>Speicher feinjustieren: Overcommit, Swappiness und Caches<\/h2>\n\n<p>Wer OOM-Risiken beherrschen will, justiert Kernel-Parameter mit Bedacht und versteht ihre Wechselwirkung. <code>vm.overcommit_memory<\/code> und <code>vm.overcommit_ratio<\/code> steuern, wie gro\u00dfz\u00fcgig Linux virtuelle Zuteilungen erlaubt, w\u00e4hrend <code>vm.swappiness<\/code> das Verh\u00e4ltnis von Swapping zu Reclaim beeinflusst. <code>vm.vfs_cache_pressure<\/code> regelt die Aggressivit\u00e4t beim Freigeben von Inode- und Dentry-Caches und wirkt damit direkt auf den Spielraum des Page\u2011Caches. Ich pr\u00fcfe Effekte immer unter realistischer <strong>Last<\/strong>, logge die Metriken und \u00e4ndere nur schrittweise. F\u00fcr Hintergr\u00fcnde und Szenarien hilft ein Blick auf <a href=\"https:\/\/webhosting.de\/memory-overcommitment-virtualisierung-ram-optimus\/\">Memory Overcommit<\/a>, um die eigenen Defaults sinnvoll zu w\u00e4hlen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameter\/Kennzahl<\/th>\n      <th>Rolle im System<\/th>\n      <th>Wo pr\u00fcfen<\/th>\n      <th>\u00dcbliche Richtung<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Freier RAM<\/td>\n      <td>Puffer gegen harte Kills<\/td>\n      <td>free, \/proc\/meminfo<\/td>\n      <td>Genug Reserve halten<\/td>\n    <\/tr>\n    <tr>\n      <td>Swap\u2011Nutzung<\/td>\n      <td>Sto\u00dfd\u00e4mpfer f\u00fcr Peaks<\/td>\n      <td>free, vmstat<\/td>\n      <td>Niedrig bis moderat<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.overcommit_memory<\/td>\n      <td>Virtuelle Zuteilung<\/td>\n      <td>sysctl<\/td>\n      <td>0\/2 je nach Risiko<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.overcommit_ratio<\/td>\n      <td>Quote f\u00fcr Overcommit<\/td>\n      <td>sysctl<\/td>\n      <td>Passend zur Workload<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.swappiness<\/td>\n      <td>Swap\u2011Neigung<\/td>\n      <td>sysctl<\/td>\n      <td>Mittelwert statt Extrem<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.vfs_cache_pressure<\/td>\n      <td>Reclaim von VFS\u2011Caches<\/td>\n      <td>sysctl<\/td>\n      <td>100 als Startpunkt<\/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\/07\/ooom-killer-linux-0843.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Globaler OOM vs. Cgroup\u2011OOM: was genau stirbt?<\/h2>\n\n<p>In modernen Setups mit Cgroups (v1\/v2) kann ein OOM\u2011Ereignis <strong>lokal<\/strong> in einer Memory\u2011Cgroup oder <strong>global<\/strong> auf dem Host ausgel\u00f6st werden. L\u00e4uft ein Prozess in einem Container mit striktem <em>memory.max<\/em> (bzw. Limit), beendet der Kernel typischerweise nur Prozesse in dieser Cgroup (\u201ememcg OOM\u201c), w\u00e4hrend das Gesamtsystem weiterl\u00e4uft. In <code>dmesg<\/code> erkenne ich das an Hinweisen wie <em>constraint=CONSTRAINT_MEMCG<\/em> oder Hinweisen auf die betroffene Cgroup. Erst wenn keine Cgroup mehr RAM hergeben kann und globaler Speicher ersch\u00f6pft ist, greift der <strong>systemweite<\/strong> OOM Killer. F\u00fcr Stabilit\u00e4t ist mir wichtig, Limits so zu setzen, dass ein \u00fcbergriffiger Dienst in seiner Cgroup scheitert, statt den ganzen Host mitzurei\u00dfen. In Cgroups v2 kann ich zus\u00e4tzlich mit <em>memory.high<\/em> weiche Drosselungen setzen und mit <em>memory.oom.group<\/em> definieren, dass im Ernstfall die gesamte Gruppe endet \u2013 sauberer als ein halblebiger Restprozess.<\/p>\n\n<h2>Werkzeuge und Metriken in der Praxis<\/h2>\n\n<p>Zur schnellen Ursachenforschung sammle ich reproduzierbare Zahlen. Diese Werkzeuge helfen mir regelm\u00e4\u00dfig:<\/p>\n\n<ul>\n  <li><strong>Prozess\u2011\u00dcbersicht<\/strong>: <code>ps -eo pid,ppid,cmd,%mem,rss --sort=-rss | head<\/code> zeigt Speicherfresser an.<\/li>\n  <li><strong>Smaps\u2011Rollup<\/strong>: <code>cat \/proc\/&lt;PID&gt;\/smaps_rollup<\/code> liefert RSS\/PSS\/Swap eines Prozesses ohne langes Parsen.<\/li>\n  <li><strong>pmap<\/strong>: <code>pmap -x &lt;PID&gt; | sort -nrk3 | head<\/code> listet Mappings mit Gr\u00f6\u00dfe und RSS, gut f\u00fcr Heaps und gro\u00dfe Segmenten.<\/li>\n  <li><strong>Slab\u2011Nutzung<\/strong>: <code>slabtop -o<\/code> zeigt Kernel\u2011Caches, die bei hoher Last anschwellen k\u00f6nnen.<\/li>\n  <li><strong>Systemdruck<\/strong>: <code>vmstat 1<\/code> und <code>sar -r 1<\/code> geben Kontext zu Paging, Swap\u2011I\/O und Frees.<\/li>\n  <li><strong>Cgroup\u2011Stats<\/strong>: In v2 pr\u00fcfe ich <code>\/sys\/fs\/cgroup\/memory.current<\/code>, <code>memory.swap.current<\/code> und <code>memory.stat<\/code> des betroffenen Services.<\/li>\n<\/ul>\n\n<pre><code># OOM-Spuren komfortabel lesen\ndmesg -T | egrep -i 'out of memory|oom-kill|killed process'\n\n# Top-Kandidaten nach oom_score sortieren\nfor p in \/proc\/[0-9]*; do\n  pid=${p##*\/}\n  [ -r \"$p\/oom_score\" ] || continue\n  printf \"%6s  %5s  %-30s\\n\" \\\n    \"$(cat $p\/oom_score)\" \\\n    \"$(cat $p\/oom_score_adj 2>\/dev\/null || echo 0)\" \\\n    \"$(tr -d '\\0' &lt; $p\/comm)\"\ndone | sort -nr | head -n 20\n<\/code><\/pre>\n\n<p>Wenn ich wiederholt OOMs sehe, dokumentiere ich die <strong>Baseline<\/strong> dieser Werte unter Normalbetrieb und vergleiche sie mit dem Vorfallfenster. Abweichungen springen sofort ins Auge, etwa ein ungebremster Anstieg von PSS oder unverh\u00e4ltnism\u00e4\u00dfig gro\u00dfe Slabs.<\/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\/07\/oomkiller_linuxprocesses_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systemd, Container und Orchestrierung: gezielt steuern<\/h2>\n\n<p>Unter systemd setze ich die Priorisierung und Grenzen <strong>deklariert<\/strong> in Unit\u2011Dateien:<\/p>\n\n<pre><code>[Service]\n# Prozess sch\u00fctzen oder opferbar machen\nOOMScoreAdjust=-900\n\n# Harte\/Weiche Speicherlimits (cgroup v2)\nMemoryMax=8G\nMemoryHigh=6G\n# Optional: Swap begrenzen\nMemorySwapMax=2G\n\n# Verhalten bei OOM unter systemd\n# (z.B. Neustart erzwingen)\nRestart=on-failure\nRestartSec=5\n<\/code><\/pre>\n\n<p>In Container\u2011Umgebungen sorge ich f\u00fcr klare Grenzwerte pro Service. Wichtig ist mir die Unterscheidung von <strong>Request<\/strong> (geplante Reservierung) und <strong>Limit<\/strong> (harte Obergrenze). Pods mit passenden Requests\/Limits erhalten bessere QoS\u2011Einstufungen; \u201eBestEffort\u201c-Workloads sind OOM\u2011gef\u00e4hrdet. Ein Praxisdetail: Beendet der Kernel einen Container wegen Cgroup\u2011OOM, sehe ich h\u00e4ufig Exitcode <strong>137<\/strong> und Ereignisse mit <em>OOMKilled<\/em>; im Host\u2011<code>dmesg<\/code> l\u00e4sst sich das korrelieren. In produktiven Clustern plane ich kritische Deployments als \u201eGuaranteed\u201c, w\u00e4hrend Batch\u2011Jobs bewusst enger laufen und damit zuerst Platz machen.<\/p>\n\n<h2>Kernel\u2011Details: OOM Reaper, THP und Fragmentierung<\/h2>\n\n<p>Nach dem Kill greift der <strong>OOM Reaper<\/strong>: ein Kernel\u2011Thread entzieht dem Opferprozess so schnell wie m\u00f6glich sein Speichermapping, damit RAM wirklich frei wird. Das erkl\u00e4rt, warum Speicher manchmal erst <em>nach<\/em> dem Killeintrag sichtbar zur\u00fcckkommt. Parallel dazu kann die <strong>Speicherkompaktierung<\/strong> an Grenzen sto\u00dfen \u2013 ist der RAM stark fragmentiert, fehlen zusammenh\u00e4ngende Bereiche f\u00fcr gro\u00dfe Allokationen (etwa mit Transparent Huge Pages, THP). THP liefert Performance, kann aber unter Druck Zuteilungen erschweren. F\u00fcr latenzkritische Workloads deaktiviere oder begrenze ich THP testweise und messe die Auswirkungen.<\/p>\n\n<p>Ein weiterer Faktor sind <strong>Slab\u2011Caches<\/strong> und der Page\u2011Cache: Unter I\/O\u2011lastigen Workloads wachsen diese Caches stark. Mit <code>vm.vfs_cache_pressure<\/code> und gezieltem Reclaim l\u00e4sst sich ihr Anteil steuern; pauschales Leeren (Drop\u2011Caches) setze ich h\u00f6chstens als Diagnoseinstrument ein, nicht als Dauerl\u00f6sung. Zudem achte ich auf <strong>NUMA<\/strong>: Ist ein Speicher\u2011Knoten ersch\u00f6pft, kann ein Prozess in dieser NUMA\u2011Zone trotz global freiem RAM scheitern. Entsprechende Hinweise tauchen ebenfalls in den Kernel\u2011Logs auf.<\/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\/07\/oom-killer-linux-processes-9021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Swap\u2011Strategien vertiefen: Swappiness, ZRAM\/Zswap, I\/O\u2011Budget<\/h2>\n\n<p>Swap ist kein \u00dcbel, sondern ein <strong>Sto\u00dfd\u00e4mpfer<\/strong>. Entscheidend ist, ihn klug einzusetzen. Mit <code>vm.swappiness<\/code> reguliere ich, wie fr\u00fch der Kernel in Swap ausweicht. Zu niedrige Werte lassen den Page\u2011Cache dominieren und k\u00f6nnen OOMs fr\u00fcher triggern; zu hohe Werte verlagern Druck in Swap\u2011I\/O und machen das System tr\u00e4ge. In kompakten Hosts nutze ich gern <strong>ZRAM<\/strong> oder <strong>Zswap<\/strong>, um einen komprimierten Puffer zu schaffen, der Peaks abf\u00e4ngt, ohne die Platte zu \u00fcberlasten. Wichtig bleibt: Swap ist kein Ersatz f\u00fcr fehlende Kapazit\u00e4t. Er kauft nur Zeit, damit der OOM\u2011Killer gar nicht erst z\u00fcnden muss.<\/p>\n\n<h2>Spezialf\u00e4lle: mlock, RLIMITS, Overcommit\u2011T\u00fccken<\/h2>\n\n<p>Einige Randbedingungen verst\u00e4rken OOM\u2011Risiken oder ver\u00e4ndern das Verhalten:<\/p>\n\n<ul>\n  <li><strong>Gesperrter Speicher<\/strong>: Prozesse, die via <code>mlock()<\/code> Seiten pinnen, entziehen sie dem Reclaim. Bei hoher Rate kann das Reaper\u2011Tempo ausgebremst werden.<\/li>\n  <li><strong>RLimits<\/strong>: <code>RLIMIT_AS<\/code> und <code>RLIMIT_RSS<\/code> setzen pro Prozess Obergrenzen und verhindern, dass einzelne Dienste ausufern \u2013 ein Baustein gegen OOMs.<\/li>\n  <li><strong>Overcommit<\/strong>: Zu gro\u00dfz\u00fcgige Overcommit\u2011Einstellungen erlauben gro\u00dfen virtuellen Adressraum, der sp\u00e4ter physisch nicht zu decken ist. Gerade Allokationsspitzen vieler Threads f\u00fchren dann gleichzeitig zu Fehlgriffen und beschleunigen OOM\u2011Events.<\/li>\n  <li><strong>panic_on_oom<\/strong>: F\u00fcr hochkritische Systeme existiert die Option, bei OOM mit einem Kernel\u2011Panic zu reagieren. Das ist nur in eng definierten HA\u2011Szenarien sinnvoll und sonst kontraproduktiv.<\/li>\n  <li><strong>\u201eUnkillbar\u201c ist riskant<\/strong>: <code>oom_score_adj=-1000<\/code> sch\u00fctzt zwar vor dem Killer, kann aber das Gesamtsystem blockieren. Ich setze das nur f\u00fcr absolut essentielle, kleine Prozesse ein (z. B. init), nicht f\u00fcr speicherhungrige Serverdienste.<\/li>\n<\/ul>\n\n<h2>Praxis: Priorit\u00e4ten festlegen und \u00c4nderungen absichern<\/h2>\n\n<p>Ich definiere im Team eine <strong>Rangliste<\/strong> der Dienste: Was muss bleiben, was darf zuerst gehen? Diese Ordnung \u00fcbersetze ich in <code>oom_score_adj<\/code>, Cgroup\u2011Limits und (wo verf\u00fcgbar) Restart\u2011Politiken. \u00c4nderungen flie\u00dfen als Code in Unit\u2011 oder Deployment\u2011Manifeste, begleitet von Messpunkten im Monitoring. In Lasttests simuliere ich Speicherdruck: Erh\u00f6he Datenmengen, drehe die Parallelit\u00e4t hoch, lasse Caches anwachsen \u2013 und beobachte, ob genau die \u201eopferbaren\u201c Prozesse fallen, w\u00e4hrend Kernst\u00fccke online bleiben. Erst wenn das reproduzierbar funktioniert, kommt die Konfiguration in Produktion.<\/p>\n\n<h2>Diagnosemuster: Leaks, Heaps und Fragmentierung unterscheiden<\/h2>\n\n<p>Nicht jeder steigende RSS ist ein Leak. Ich unterscheide systematisch:<\/p>\n\n<ul>\n  <li><strong>Leak<\/strong>: RSS\/PSS steigen monoton, auch ohne steigende Last; <code>smaps_rollup<\/code> w\u00e4chst gleichm\u00e4\u00dfig, GC\u2011Zyklen (bei Managed Runtimes) helfen nicht.<\/li>\n  <li><strong>Heap\u2011Spitzen<\/strong>: RSS steigt mit Last und f\u00e4llt wieder; Page\u2011Cache korreliert mit I\/O\u2011Mustern.<\/li>\n  <li><strong>Fragmentierung<\/strong>: Ausreichend freier RAM, aber gro\u00dfe Allokationen scheitern; Logs zeigen Kompaktierungsversuche, THP\u2011Zuteilungen misslingen \u00f6fter.<\/li>\n<\/ul>\n\n<p>F\u00fcr JVM\u2011 oder Node\u2011Workloads pr\u00fcfe ich, ob die Runtime die Container\u2011Limits erkennt. Zu gro\u00df dimensionierte Heaps oder JIT\u2011Code\u2011Caches k\u00f6nnen am Limit vorbeiplanen und OOMs provozieren, obwohl noch scheinbar Luft ist. Ich setze Heaps inkl. Overhead so, dass unter <em>MemoryMax<\/em> noch Puffer f\u00fcr Native\u2011Anteile, Thread\u2011Stacks und Page\u2011Cache bleibt.<\/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\/07\/oom_killer_techoffice_9123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Playbook f\u00fcr Rollouts und Lasttests unter Speicherdruck<\/h2>\n\n<ol>\n  <li><strong>Baseline messen<\/strong>: RSS\/PSS pro Dienst, Slab\u2011Anteile, Swap\u2011Quote, Cache\u2011Gr\u00f6\u00dfen, <code>oom_score<\/code>.<\/li>\n  <li><strong>Grenzen setzen<\/strong>: <em>MemoryHigh\/Max<\/em> oder Container\u2011Limits mit realistischem Puffer definieren; <code>OOMScoreAdjust<\/code> nach Priorit\u00e4t vergeben.<\/li>\n  <li><strong>Stress erzeugen<\/strong>: Datenvolumen, Concurrency, Cache\u2011Wachstum; I\/O\u2011 und CPU\u2011Profile notieren.<\/li>\n  <li><strong>Beobachten<\/strong>: <code>dmesg -T<\/code>, Host\u2011 und Cgroup\u2011Metriken; pr\u00fcfen, wer zuerst unter Druck ger\u00e4t.<\/li>\n  <li><strong>Iterieren<\/strong>: Limits\/Adj justieren, Swappiness anpassen, THP\u2011Einstellungen testen, erneut messen.<\/li>\n  <li><strong>Automatisieren<\/strong>: Checks in CI\/CD verankern, Alarme bei Grenzwerten, Neustart\u2011Politiken f\u00fcr Opferdienste.<\/li>\n<\/ol>\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\/07\/ooom-killer-linux-0843.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurz zusammengefasst: handfeste Schritte<\/h2>\n\n<p>Ich verstehe den OOM Killer als <strong>Signal<\/strong>, dass mein System vorher zu wenig Puffer hatte oder Prozesse falsch priorisiert waren. Mit Monitoring, realistischen Limits, sauberer Swap-Strategie und einem bewussten Einsatz von <code>oom_score_adj<\/code> reduziere ich harte Absch\u00fcsse deutlich. In produktiven Setups sch\u00fctze ich Kernprozesse, mache Randdienste entbehrlich und messe jede \u00c4nderung. Bei Containern lege ich Cgroup-Grenzen strikt fest, damit ein Dienst nicht das gesamte Hostsystem blockiert. Wer diese Disziplin beibeh\u00e4lt, h\u00e4lt Linux auch unter Druck reaktionsf\u00e4hig und verk\u00fcrzt die Zeit bis zur Ursache deutlich.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo funciona el OOM Killer en Linux cuando hay falta de memoria, c\u00f3mo termina los procesos y c\u00f3mo, como administrador en entornos de alojamiento web, puedes evitar los problemas de falta de memoria utilizando la palabra clave \u00aboom killer linux\u00bb.<\/p>","protected":false},"author":1,"featured_media":20197,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20204","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":"158","_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":"oom killer linux","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":"20197","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20204","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20204"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20204\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20197"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20204"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20204"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20204"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}