How to Fix Oracle Cloud Free Tier Out of Memory (OOM) Crashes

How to Fix Oracle Cloud Free Tier Out of Memory (OOM) Crashes

There is nothing more disorienting for a developer than launching a fresh Oracle Cloud Free Tier instance, configuring Nginx and MySQL, deploying a website, and then suddenly finding that the database service has vanished into thin air. You run sudo systemctl status mysql or check your web application logs, only to find cryptic termination messages like Out of memory: Kill process 1421 (mysqld) or a abrupt single word: Killed.

This phantom crash behavior is caused by the Linux kernel's internal emergency safeguard: the Out of Memory (OOM) Killer. When a virtual machine exhausts all physically available Random Access Memory (RAM), the operating system kernel cannot allocate memory requested by active applications. To prevent the entire operating system from deadlocking or suffering file system corruption, Linux kernel algorithms automatically calculate process penalty scores and forcefully terminate memory-heavy background processes. Because Oracle Cloud Infrastructure (OCI) Free Tier Always Free x86 instances come provisioned with 1GB of physical RAM and zero Swap space configured by default, even modest web traffic spikes, search crawler indexing, or database background maintenance tasks will trigger immediate process termination.

If you have already resolved your initial network connectivity by following our tutorial on Opening Ports 80 & 443 on Oracle Cloud VPS, configuring a virtual Swap file is the next step to keep the server stable and your data safe.

Looking for zero-maintenance server stability? Skip manual kernel tuning and swap files with RackUp’s managed hosting, where each site gets its own reserved RAM.

Understanding Linux Swap & The Kernel OOM Killer

Why do Oracle Cloud Free Tier instances experience sudden process terminations far more frequently than traditional virtual private server (VPS) hosting providers?

Physical RAM is high-speed, volatile hardware memory utilized by your CPU to execute active application threads. When Linux web applications require more memory than physically installed, modern operating systems rely on Swap Space. Swap is a reserved portion of your storage drive (such as an NVMe SSD) formatted specifically to emulate additional virtual RAM. When physical RAM fills up, the Linux kernel gracefully moves idle memory pages out of RAM and writes them to the Swap drive, freeing up physical memory for active processes.

When Swap space is absent (0 Bytes allocated), Linux lacks any memory safety buffer. The kernel executes its internal oom_killer() routine, selects the process consuming the largest memory footprint (which is almost universally mysqld, mariadbd, php-fpm, or node), and sends a non-catchable SIGKILL signal. The application stops instantly without writing data buffers to disk, leading to database table corruption and broken web pages.

Step 1: Check Current Memory Allocation & Active Swap

Connect to your Oracle Cloud instance via SSH using your terminal or PuTTY, and inspect your server's current hardware memory status by running:

# Display memory and swap usage in human-readable megabytes and gigabytes
free -h

# Inspect active swap devices and file paths
sudo swapon --show

Inspect the output under the Swap: row. If the total capacity reads 0B, your virtual server has no virtual memory overflow buffer and will terminate database applications the moment memory usage hits 100%.

Step 2: Create a 2GB or 4GB Linux Swap File

We will create a dedicated 2GB Swap file on your NVMe storage drive. For 1GB physical RAM instances, allocating 2GB of Swap space provides the optimal ratio between memory protection and drive read/write performance.

Execute the following commands in sequence inside your server terminal:

# Allocate a contiguous 2 Gigabyte file named /swapfile using fallocate
sudo fallocate -l 2G /swapfile

# Fallback method: If your filesystem does not support fallocate, use dd:
# sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

# Restrict file permissions so only the root user can read or write to swap
sudo chmod 600 /swapfile

# Format the allocated binary file as Linux Swap filesystem
sudo mkswap /swapfile

# Activate the swap file immediately in the running kernel
sudo swapon /swapfile

Verify that your new virtual memory is active by executing free -h. You should now observe 2.0Gi listed under the Swap column!

Step 3: Ensure Permanent Swap Mounting Across Server Reboots

By default, Swap space initialized via the swapon command exists only in volatile memory and will be unmounted whenever your Oracle Cloud instance reboots. To make the Swap file permanent across system restarts, append its mount path to the Linux system file system table (/etc/fstab):

# Create a safety backup of your fstab configuration file
sudo cp /etc/fstab /etc/fstab.bak

# Append the swapfile mounting entry to /etc/fstab
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Step 4: Tune Kernel Swappiness and Cache Pressure Parameters

The Linux kernel governs Swap behavior using two key kernel runtime variables configured via sysctl:

1. Swappiness (vm.swappiness): A percentage value between 0 and 100 defining how aggressively Linux shifts memory pages from physical RAM to Swap. Default Linux desktop settings use 60. For VPS environments, a swappiness setting between 10 and 20 prevents unnecessary disk I/O latency while maintaining emergency protection against OOM crashes.

2. VFS Cache Pressure (vm.vfs_cache_pressure): Governs how aggressively the kernel reclaims file system directory and inode structures from RAM. Lowering this value from 100 to 50 keeps file metadata cached in RAM, improving web server file access speeds.

Apply these permanent kernel performance parameters by appending them to /etc/sysctl.conf:

# Configure swappiness to 20
echo 'vm.swappiness=20' | sudo tee -a /etc/sysctl.conf

# Configure VFS cache pressure to 50
echo 'vm.vfs_cache_pressure=50' | sudo tee -a /etc/sysctl.conf

# Reload sysctl settings into the active kernel without rebooting
sudo sysctl -p

Step 5: Configure MySQL & MariaDB Memory Boundaries

In addition to system-level Swap configuration, tuning your database engine config file (located at /etc/mysql/my.cnf or /etc/mysql/mariadb.conf.d/50-server.cnf) prevents MySQL from attempting to reserve more memory than your physical hardware can supply:

[mysqld]
# Restrict InnoDB Buffer Pool to 256MB on 1GB RAM instances
innodb_buffer_pool_size = 256M
max_connections = 40
performance_schema = OFF
key_buffer_size = 32M
table_open_cache = 400

Save the file and restart your database daemon by running sudo systemctl restart mysql.

For more detailed walkthroughs on setting up application stacks on Oracle Cloud, explore our guide on Setting up WordPress on Oracle Cloud Free Tier.

Advanced Troubleshooting: Diagnostic Logs & Monitoring

To confirm that your OOM errors have been resolved, monitor kernel system logs using journalctl or dmesg:

# Search system logs for OOM killer activity
sudo dmesg -T | grep -i oom

# Inspect system log history for process kills
sudo journalctl -u mysql --since "24 hours ago"

If the output returns empty, your Linux Swap file is performing properly, buffering transient traffic surges and protecting your database from sudden termination.

Frequently Asked Questions (FAQ)

Will adding a Swap file degrade NVMe SSD performance?
Modern cloud storage drives handle swap operations efficiently. By configuring vm.swappiness=20, Linux utilizes Swap exclusively during high-memory spikes rather than continuous operations, preserving drive lifespan while protecting uptime.

How much Swap space should I allocate on 24GB ARM Ampere instances?
For Oracle Cloud ARM Ampere instances provisioned with 6GB to 24GB RAM, a 4GB Swap file provides ample safety overhead for high-concurrency Node.js, Docker, or WordPress environments.

Why does MySQL still crash even after enabling Swap?
If crashes persist, verify your innodb_buffer_pool_size parameter. Setting buffer pools larger than total physical RAM forces constant disk thrashing that can overwhelm the operating system.

What is the difference between Swap files and Swap partitions?
Swap partitions require dedicated drive partitioning during OS installation. Swap files offer identical performance benefits on modern Linux kernels while allowing flexible sizing and creation on existing file systems without repartitioning.

Database Tuning for 1GB RAM Instances: Calibrating MySQL InnoDB Buffer Pools

While configuring a 2GB to 4GB swap file provides an essential safety net against sudden out-of-memory kernel panics, relying on disk swap for continuous memory allocation will degrade system performance. Disk I/O—even on cloud SSDs—is orders of magnitude slower than physical RAM. Therefore, the long-term solution to preventing OOM crashes on 1GB RAM cloud instances is calibrating database and PHP memory limits.

By default, modern MySQL 8.0 and MariaDB distributions configure the InnoDB Buffer Pool to consume up to 128MB to 512MB of RAM. On a 1GB instance running NGINX, PHP-FPM, Redis, and SSH, this default allocation leaves virtually zero headroom for dynamic PHP workers, causing the Linux Kernel OOM Killer to terminate mysqld during moderate traffic spikes.

To prevent database memory exhaustion, adjust your MySQL configuration file (/etc/mysql/my.cnf or /etc/mysql/mysql.conf.d/mysqld.cnf):

[mysqld]
# Restrict InnoDB memory pool on 1GB RAM instances
innodb_buffer_pool_size = 256M
innodb_log_buffer_size = 16M
max_connections = 50
key_buffer_size = 32M
table_open_cache = 400

Restart your database service to apply the new memory parameters:

sudo systemctl restart mysql

For comprehensive caching techniques that offload repeated database queries into system memory, explore our guide on how to speed up WordPress with NGINX FastCGI and OPcache. If you are developing features or testing new plugins on your instance, always test changes in an isolated sandbox using our guide on setting up a WordPress staging site.

Prefer not to manage the server yourself? Compare RackUp’s hosting plans: Cloud WordPress hosting starts at $2.49 a month.

Configuring systemd-oomd & Automated Process Watchdogs

In addition to configuring Linux disk swap and adjusting MySQL buffer pools, modern Linux operating systems (such as Ubuntu 22.04 LTS and 24.04 LTS) include the systemd-oomd user-space out-of-memory daemon. Unlike the traditional kernel OOM killer which abruptly terminates the process using the most memory (frequently your database), systemd-oomd monitors Pressure Stall Information (PSI) and intervenes before system thrashing locks up the entire server.

Furthermore, you can configure automated restart watchdogs inside systemd unit files so that if PHP-FPM or MySQL ever encounters an unexpected memory termination, the operating system immediately restarts the daemon without requiring manual SSH intervention:

# Add to /etc/systemd/system/mysql.service.d/override.conf
[Service]
Restart=on-failure
RestartSec=5s

Reload systemd to enable automated service recovery:

sudo systemctl daemon-reload

Calibrating PHP-FPM Process Managers on Constrained Cloud Instances

In addition to MySQL tuning, misconfigured PHP-FPM process managers are the most frequent cause of Out of Memory kernel panics. The default dynamic process manager spawns new PHP child workers whenever web traffic spikes. On a 1GB RAM instance, if 10 PHP child processes spawn simultaneously, each consuming 45MB of RAM, your operating system runs out of physical memory within seconds.

To prevent worker exhaustion, edit your PHP-FPM pool configuration (/etc/php/8.3/fpm/pool.d/www.conf) to cap maximum child processes strictly:

[www]
pm = ondemand
pm.max_children = 5
pm.process_idle_timeout = 10s
pm.max_requests = 500

The ondemand governor automatically terminates idle PHP processes after 10 seconds of inactivity, freeing system RAM immediately for database caching and system background daemons.

Monitoring Real-Time Memory Pressure with Htop and Vmstat

To effectively diagnose memory bottlenecks before the Linux kernel terminates critical system processes, administrators should monitor memory pressure using active command-line utilities:

# Monitor real-time memory and CPU utilization per process
htop

# Check virtual memory statistics and swap in/out frequency
vmstat 1 10

If the si (swap in) and so (swap out) columns consistently display non-zero values during normal browsing traffic, your instance is continuously swapping memory pages to disk. This indicates that your active daemon allocations exceed physical RAM, signaling an immediate need to adjust buffer pools or move to a server with more dedicated memory.