Skip to content 
I'll explain the OOM Score and OOM Score Adjust as specific control mechanisms in hosting operations: They determine which processes the Linux OOM killer terminates when memory is low and which ones it protects. This way, I stay in control when RAM is running low, and make sure that essential services remain online.
Key points
To help you get your bearings quickly, I'll briefly summarize the key points.
- Priority In case of scarcity: The OOM score determines which process must be terminated first.
- Fine control with oom_score_adj: From -1000 (protect) to +1000 (sacrifice).
- Dynamics Instead of a fixed value: The rating changes depending on the load and configuration.
- Hosting practice: Protect critical services; terminate non-critical workers.
- Causes Resolve: Check limits, cgroups, and RAM scheduling.
How the Linux OOM Killer Works
When high storage pressure The Linux kernel decides which processes to terminate in order to keep the system responsive. I observe how the Kernel assigns each process a sort of „badness“ score that depends heavily on its current memory usage. If there isn’t enough free RAM or swap space, the OOM killer steps in and terminates the process with the highest score. This mechanism prevents system freezes but is no substitute for proper capacity planning at the host and service levels. I review the decision in the OOM log to determine whether a service became problematic due to memory hunger or misconfiguration.
Understanding the OOM Score: Dynamics and Scale
I check the OOM Score of a process in /proc/PID/oom_score to determine how at risk it currently is. The scale ranges from 0 to 1000: the closer the value is to 1000, the more likely the process is to be killed. This value represents a snapshot, because load spikes, cgroup limits, and cache sizes are constantly changing. That’s why I never evaluate the score in isolation, but rather in the context of memory, swap, overcommit, and concurrent processes. If you monitor the score regularly, you’ll recognize typical patterns and can anticipate bottlenecks before they take services offline.
Using OOM Score Adjust Strategically
With oom_score_adj I actively adjust a process's rating from -1000 to +1000. If I set it to -1000, I fully protect the process, while high positive values deliberately make it a candidate for termination. I choose these values sparingly, because too many protected processes limit the OOM killer’s ability to act. Typical candidates for low values are SSH, monitoring, reverse proxy front ends, and sensitive database controllers. Background jobs, reporters, or short-lived workers tend to receive a higher adjustment so that the user interface remains responsive when resources are tight.
Setting Priorities in Hosting
In productive setups, I define clear Priorities between the front end, API, database, and batch processing. I first determine which services must remain running from the user’s perspective and assign them an appropriate OOM adjustment. In systemd, I set `OOMScoreAdjust=` in the service unit file and document the purpose of each value. If you manage services via systemd anyway, you can streamline your workflows; a good place to start is systemd in Hosting. This way, I proactively address outages instead of leaving them to chance, and ensure that the user experience remains reliably online.
Cgroups, Containers, and Limits
I'll never forget the cgroups, because containers and services operate in their own resource environments. A process with a moderate OOM score can still crash if its cgroup has a tight memory limit and the process briefly exceeds it. That’s why I check limits in cgroup v2 and configure hard and soft limits to match load profiles. Those who operate multi-tenancy or shared hosting benefit from properly configured quotas and accounting; more background information is provided by cgroup v2 in Hosting. When everything works together properly, OOM adjustment and limits function like a well-calibrated pair of adjustment screws.
Diagnosis and Monitoring of OOM Events
When things get intense, I need clear Signals and reproducibility in the analysis. I analyze dmesg, journald, and /var/log/kern.log, save the OOM lines, and retrieve the victim’s PID along with its oom_score and oom_score_adj. For routine checks, I use scripts that list the largest memory consumers and trigger warning thresholds. Anyone who wants to dive deeper will find a structured approach in the OOM Killer Analysis. In production environments, I incorporate metrics such as RSS, cache, swap-in/out, and container limits into my monitoring so that I can identify trends early on.
Table-Format Cheat Sheet for Admins
I use the following overview as a concise Guide, when I prioritize roles and document adjustments. The „Reason“ column explains why a role is assigned protection or sacrifice. I adjust the numbers to fit the project, but the general approach helps with quick decisions. Anyone who uses the table as a starting point gains clarity during post-mortems and when proposing changes. The key point is this: I always maintain a buffer in the overall system so that hard kills are rarely necessary.
| Component | Typical destination | Example: oom_score_adj | Reason |
|---|---|---|---|
| SSH-Daemon | Shooters | -500 to -900 | Ensure access for procedures, even during bottlenecks. |
| Reverse Proxy (nginx/HAProxy) | Shooters | -300 to -700 | Handle incoming traffic; return error pages. |
| DB-Controller/Primary Instance | Shooters | -200 to -600 | Maintain connections, ensure data access. |
| PHP-FPM/Application Workers | Neutral to willing to make sacrifices | 0 to +300 | Many parallel workers can be removed. |
| Batch/Backup/Reports | Willing to make sacrifices | +300 to +800 | Can be rescheduled without affecting users. |
| Indexer/Queue Consumer | Willing to make sacrifices | +200 to +600 | You can pause briefly and catch up later. |
How to Properly Limit WordPress and PHP Workers
With WordPress, I pay attention to Worker-Number of processes, `memory_limit`, and resource-intensive operations like image processing or imports. I configure PHP-FPM so that the number of active processes matches the amount of RAM and doesn’t cause an avalanche of processes. For the database, I add up the buffer and cache sizes and leave some headroom so that spikes don’t block everything. I monitor OpCache, the object cache, and the image optimizer because they can quickly drive up memory usage. This way, I ensure that brief load spikes don’t immediately take down the critical front-end processes.
In Practice: Policies and Playbooks
I keep my Policies Concise and actionable, so the team doesn’t hesitate in an emergency. This includes: defining protection candidates, specifying victim roles, setting `OOMScoreAdjust=` on systemd units, and documenting the values in the repo. I test the effectiveness using tools and test loads until the order of the sacrificial units aligns with the objectives. Afterward, I write a playbook that describes logs, alerts, and initial response measures. This ensures a consistent response, even when new colleagues take over.
# Sample code snippet for a systemd unit
[Service]
OOMScoreAdjust=-400
# Reload and restart:
# systemctl daemon-reload && systemctl restart nginx
# Check while running:
cat /proc/$(pidof nginx)/oom_score
cat /proc/$(pidof nginx)/oom_score_adj
# Temporarily increase/decrease (root):
echo 300 | sudo tee /proc//oom_score_adj
Common errors and countermeasures
Many problems arise because Limits Don't mix these: too many PHP workers, DB caches that are too large, and no room for load spikes. Then the OOM killer kicks in regularly, even though just a few tweaks would suffice. I adjust the number of workers first, measure the effect, and only increase the RAM if the need is clearly evident. Setting many processes to -1000 is also harmful, because the kernel needs room to maneuver. I prioritize with a sense of proportion so that the system can respond in an orderly manner in an emergency.
Overcommit, Swap, and Memory Levels
I'm putting my Overcommit Strategy I set this value deliberately, because it determines how quickly a system enters the OOM zone. With `vm.overcommit_memory=0` (heuristic), I often get stable performance because the kernel estimates the commit limit based on usage and history. Things get stricter with `vm.overcommit_memory=2` plus `vm.overcommit_ratio`, which defines the maximum allowed virtual memory allocation. Anyone who sets vm.overcommit_memory=1 across the board risks memory reservations succeeding initially only to fail catastrophically later during allocation—a common cause of OOM events under load.
I calibrate Swap so that it provides a buffer without becoming a latency killer. A moderate vm.swappiness setting keeps pure memory free for hot paths, while rarely used pages are swapped out. I can use zswap or zram as an elastic buffer when I/O is slow—this reduces the risk of OOM but costs CPU. Water levels are also important: vm.min_free_kbytes must be set high enough so that the kernel can reclaim memory in a timely manner. Setting these values too low forces the system into frantic reclaim cycles and triggers pathologies that lead to OOM.
# Example: Conservative overcommit and moderate swapping
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=90
sysctl -w vm.swappiness=30
# Add these settings to /etc/sysctl.d/ as persistent for testing
Systemd Options Beyond OOMScoreAdjust
In addition to OOMScoreAdjust, I use systemd to Energy-absorbing guardrails Set directly on the service. With `MemoryMax=`, I set a hard limit (`cgroup memory.max`); `MemoryHigh=` gently throttles performance under load; and `MemorySwapMax=` curbs swapping. `MemoryLow=` and `MemoryMin=` prioritize a service’s cache portions under pressure, so that critical processes don’t slow down as quickly. Together with OOMPolicy=, I control what systemd does at the unit level when an OOM condition occurs (e.g., just stop the service or terminate entire dependencies). I group roles—web frontend, batch, DB—into slices and derive consistent rules so that individual outliers don’t destabilize the entire system.
I realize that protection is never absolute: Even processes with -1000 may have to give way in hopeless situations. That's why I set generous but realistic Minima (MemoryLow/Min) only for a very small number of core services, and check to make sure the total of all allocations remains below the physically available memory. This prevents well-intentioned safeguards from blinding the OOM killer.
Kubernetes and Container Orchestration
In orchestration systems like Kubernetes, OOM logic operates on multiple levels. I use Requests and Limits so that pods fall into the desired QoS class: Guaranteed offers the strongest protection, Burstable provides the most flexibility, and BestEffort is the most likely to be affected. The kubelet automatically assigns the resulting OOMScoreAdjust values—so I plan based on resource specifications rather than manual tuning values within the containers. If a container hits its `memory.limit`, it terminates within its cgroup even if the host still has free memory; this is not a classic host OOM, but rather a targeted self-defense mechanism to enforce the limit.
I take into account native memory shares outside of the heap configurations (e.g., for JVM/Node) to prevent containers from unexpectedly crashing when they hit their limits. I also calculate pod buffers to account for spikes and plan node overcommitment only in moderation to ensure that evictions are rare. When cgroup v2 is enabled, I use `memory.oom.group` strategically so that, in an emergency, an entire process group shuts down in an orderly manner rather than leaving individual workers in a zombie pod. This keeps the system clean and makes recovery predictable.
Diagnostic Depth: SMaps, PSI, and Reproducible Tests
For in-depth analyses, I turn to /proc-Insights and pressure metrics. /proc/PID/status shows VmRSS, VmSwap, and threads; /proc/PID/smaps_rollup summarizes categories such as Anon, File, and Shmem without getting bogged down in the details. This is how I can tell if the page cache is misleading or if anonymous pages (actual working set) are growing. With /proc/pressure/memory, I measure PSI-Signals, i.e., how much time the system spends in active reclaim or stalls. I set alerts for these values long before an OOM condition occurs—ideal for automatically triggering countermeasures (throttling, scaling, reducing the number of workers).
# Relevant Snapshots
journalctl -k -g "Out of memory|oom-killer"
cat /proc/pressure/memory
grep -E "VmRSS|VmSwap|Threads" /proc//status
cat /proc//smaps_rollup
# Reproduce OOM (Test Environment!)
stress-ng --vm 2 --vm-bytes 80% --timeout 30s
Special Cases: JVM, Node.js, and PHP in Containers
JVM-Services require attention because, in addition to the heap, metaspace, thread stacks, direct buffers, and native allocator behavior also come into play. I use MaxRAMPercentage for container-friendly management and set a heap size that leaves headroom for these components. With high parallelism, I limit thread pools, because many small stacks add up painfully. For Node.js I adjust `-max-old-space-size` to match the container limit to prevent hard kills. And for PHP-FPM I calculate pm.max_children based on RAM, average usage per request, and memory_limit—plus a reserve for caches and the web server. This helps me prevent creeping performance issues that only become apparent during peak times.
I keep the Allocator Strategy In Focus: glibc with many arenas can fragment memory and drive up memory usage in workloads with many threads. For certain services, jemalloc or tcmalloc deliver more consistent peaks; I’m testing this specifically, documenting the effect, and rolling it out in a controlled manner. I’m also limiting tmpfs directories within the container so that uploads or temp files don’t quietly eat up RAM.
Tmpfs, Huge Pages, and Page Cache
tmpfs This is often overlooked: Without a size limit, it grows until it takes up a portion of the RAM, and suddenly there isn't enough space elsewhere. I mount tmpfs with a specific `size=` setting, especially for build or upload paths. Transparent Huge Pages (THP) Fragmentation and latency have an impact; for latency-critical services, I often use „madvise“ so that only suitable allocations benefit. KSM can deduplicate data and save memory, but it consumes CPU resources—it’s useful on development hosts, but in performance-critical environments, I evaluate its impact and overhead.
The Page Cache It is not „wasted“ memory; it speeds up I/O. If I evict it too aggressively or use drop caches as a permanent measure, I shift the cost to latency spikes. It’s better to define memory targets per role and enforce a fair balance using cgroup mechanisms (memory.high / memory.max). This keeps the hot sets of important services in RAM and makes OOM situations less frequent.
Summary for everyday life
I use the OOM Score I use it as a barometer for risk and use `oom_score_adj` to adjust the correct order of sacrifices. I protect services that impact users, mark jobs that can be postponed as candidates for sacrifice, and document every value in a traceable manner. I plan cgroup limits, the number of workers, and cache sizes as a unified whole to prevent spikes from escalating into widespread issues. Logs, monitoring, and a concise playbook ensure that I quickly detect OOM events and resolve them effectively. With this discipline, the host remains reliable, and I avoid unpleasant surprises during production nights.
