You are compiling a kernel module or opening a heavy browser session, and the terminal spits out Cannot allocate memory. The system freezes, the mouse lags, and you realize the OOM killer just murdered your database. You are staring at a hung process or a black screen, and you need to know why your RAM vanished and how to stop it from happening again.
What is actually happening
Linux manages memory aggressively. It fills physical RAM with disk cache to speed up file access, then allocates the rest to processes. When physical RAM is exhausted, the kernel looks for swap space. Swap is disk space used as slow overflow memory. If both RAM and swap are full, the kernel panics or invokes the Out-Of-Memory (OOM) killer.
The OOM killer is a safety valve, not a bug. It scores every running process based on memory usage, runtime, and privileges. The process with the highest score gets terminated to free memory and save the system. The error Cannot allocate memory usually means a process asked for memory via malloc or mmap, and the kernel refused because there was nowhere to put it. This can happen even if free memory looks low, because the kernel distinguishes between reclaimable cache and truly available memory.
The free command output can be misleading. The available column is the number that matters. It accounts for reclaimable cache and buffers. If available is low, you are in trouble. If free is low but available is high, the system is healthy and using cache efficiently. The OOM killer is a last resort. Prevent it by monitoring available memory, not free memory.
Check current memory pressure and identify the top consumers
Start by seeing what is actually consuming resources. The free command gives a quick snapshot of totals, while ps reveals which processes are hogging RAM. Fedora includes smem in the repositories for more accurate reporting, but ps is available everywhere and sufficient for immediate triage.
# Show human-readable memory and swap totals
free -h
# List top 10 processes sorted by resident memory usage
ps aux --sort=-%mem | head -11
The free -h output shows Mem: and Swap: rows. Look at available under Mem:. If that number is near zero, you have no headroom. The ps command lists processes by %mem, which is the percentage of physical RAM used. The RSS column shows Resident Set Size, the actual physical memory the process holds. Virtual memory (VSZ) includes mapped files and shared libraries, so it is often much larger than RSS and less useful for diagnosing OOM events.
If a single process is consuming most of the RAM, consider restarting it or setting resource limits. Systemd services can be capped using MemoryMax= directives in the unit file. This prevents a runaway service from starving the rest of the system.
Create and activate a swap file to provide overflow space for memory
If swap is zero or too small, add a swap file. Fedora supports swap files just as well as swap partitions, and files are easier to resize. Fedora Workstation uses Btrfs by default. Btrfs handles swap files efficiently, but you must use fallocate to create the file. Using dd creates a sparse file that Btrfs might not handle correctly for swap. Always use fallocate on Btrfs.
# Create a 4GB sparse file for swap
sudo fallocate -l 4G /swapfile
# Restrict permissions so only root can read/write
sudo chmod 600 /swapfile
# Format the file as swap space
sudo mkswap /swapfile
# Enable the swap file immediately
sudo swapon /swapfile
The fallocate command creates the file instantly without writing zeros, which is much faster than dd. The chmod 600 step is mandatory. If permissions are wrong, swapon will refuse to activate the file with an Invalid argument error. The mkswap command writes the swap signature to the file. The swapon command activates it immediately.
To make the swap file persist across reboots, add it to /etc/fstab. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with packages. Edit /etc/. Never edit /usr/lib/.
# Append swap entry to fstab for persistence across reboots
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
The sw 0 0 options disable dump and fsck checks for swap, which is standard practice. Add swap before the system locks up. A swap file takes seconds to create and buys you time to debug.
Review kernel logs to identify which process triggered the OOM killer
If the OOM killer already ran, the logs tell you what died and why. The kernel records OOM events in the ring buffer. You can search these logs to find the victim process and the trigger.
# Search journal for OOM killer activity
journalctl -k --grep="Out of memory"
# Show detailed OOM scores for running processes
cat /proc/*/oom_score_adj 2>/dev/null | head -20
The journalctl -k command limits the search to kernel messages. The oom_score_adj file in /proc/ shows the adjustment to the OOM score for each process. A value of -1000 makes a process immune to the OOM killer. A value of 1000 makes it the first target. Critical services often set this to negative values to survive OOM events. If your database keeps dying, check its score.
The OOM killer log line looks like this:
Out of memory: Killed process 12345 (java) total-vm:4567890kB, anon-rss:3456789kB, file-rss:123kB, shmem-rss:0kB
This line identifies the process name, PID, and memory breakdown. anon-rss is anonymous memory, which cannot be paged to swap if swap is full. If anon-rss is high, the process is the likely culprit.
Adjust the kernel overcommit policy if applications require strict memory guarantees
The kernel has an overcommit policy that controls how it handles memory allocation requests. The default is heuristic overcommit, where the kernel estimates whether there is enough memory and allows the allocation. Some applications, like virtualization software or build tools, require strict memory reservation. They need the kernel to guarantee that allocated memory exists.
# Check current overcommit policy
cat /proc/sys/vm/overcommit_memory
# Set policy to always allow allocations (risky for production)
sudo sysctl vm.overcommit_memory=1
The value 0 is heuristic (default). The value 1 is always allow, which means the kernel never refuses allocation until the OOM killer hits. The value 2 is strict, which means the kernel refuses allocation if there is not enough RAM plus swap. Setting vm.overcommit_memory=1 is dangerous for production systems because it can lead to sudden OOM kills when memory is exhausted. Use this setting only for specific workloads that require it.
To make the change permanent, add vm.overcommit_memory=1 to /etc/sysctl.d/99-memory.conf and run sudo sysctl --system. Sysctl changes in /etc/sysctl.d/ are user config. Files in /usr/lib/sysctl.d/ are vendor. Edit /etc/. Never edit /usr/lib/.
Verify swap is active and fstab syntax is valid
After adding swap or changing settings, verify that the system is using the new configuration. The swapon --show command lists active swap devices and their sizes. The findmnt --verify command checks fstab syntax without mounting anything.
# Confirm swap is active and size is correct
swapon --show
# Verify fstab entry parses without errors
sudo findmnt --verify --tab-file /etc/fstab
If swapon --show does not list your swap file, the system is not using it. Check permissions and filesystem support. If findmnt --verify reports errors, fix the fstab syntax before rebooting. Trust swapon --show. If it doesn't list your swap, the system isn't using it.
Common pitfalls and what the error looks like
The fallocate command may fail on certain filesystems if compression is enabled. Btrfs compression can interfere with swap files. Ensure the subvolume containing the swap file does not have compression enabled. The swapon command may fail with swapon: /swapfile: swapon failed: Invalid argument. This usually means permissions are wrong or the filesystem does not support swap files. Check chmod 600 and filesystem type.
The vm.overcommit_memory=1 setting can cause the OOM killer to trigger harder and faster. When the kernel always allows allocations, processes can consume all memory without warning. The OOM killer then has to kill multiple processes to recover. Use this setting with caution.
The oom_score_adj value is per-process. If you restart a service, the score resets to the default. Use systemd OOMScoreAdjust= directive to make the setting persistent. The free command output changes between versions. Older versions did not show available. Use free -h on modern Fedora to see the correct column.
Check permissions before crying. swapon fails silently on wrong permissions in some versions.
When to use this vs alternatives
Use a swap file when you need to resize swap space without repartitioning the disk. Use a swap partition when you are installing Fedora from scratch and want maximum performance for swap I/O. Use zram when you are running on a device with very limited storage or slow disk I/O. Tune vm.overcommit_memory when you are running virtualization or build tools that require strict memory reservation guarantees. Upgrade physical RAM when swap usage is constant and disk latency is degrading system responsiveness.
Match the tool to the constraint. Disk space, speed, and complexity dictate the choice.