The Ultimate Guide to Squeezing Every Last Bit from a 1GB RAM Host: AlmaLinux 10.2 / Webmin / Lightweight Pure PHP and MariaDB in Practice

In an affordable cloud VPS environment (such as 1GB RAM and dual-core Intel vCPUs), many open-source control panels (such as Webmin/Virtualmin) and the default configurations of underlying databases are excessively bloated. This is especially true for a production website exposed to the public and serving thousands of users per day (30,000 active users over 7 days). Without fine-tuning, it can easily trigger Linux's OOM (Out of Memory) mechanism and cause services to crash.

This article documents in detail how to apply comprehensive optimization across four dimensions—the system layer, database layer, application layer, and network defense layer—to bring available physical memory back to a safe level of 330MB+ while drastically reducing the load on MariaDB.

Chapter 1: Removing Unnecessary Components and Building Defenses at the Operating-System Layer

1. Create a 2GB Swap Buffer

When physical memory suddenly becomes insufficient, Swap provides critical fallback protection to prevent OOM crashes.

# Create a 2GB empty file
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# Configure automatic mounting at boot
echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

2. Forcefully Mask Unused Background Services

If the website does not need to send email externally, merely disabling the service in the UI is insufficient; the underlying postfix service may still be awakened by system dependencies. You must use mask to lock it down completely:

sudo systemctl stop postfix
sudo systemctl disable postfix
sudo systemctl mask postfix

3. Mitigate polkitd Memory-Leak Concerns

The polkitd authorization daemon tends to accumulate cached garbage during long periods of operation (potentially consuming up to 66MB). Since restarting it has no impact on website operation, it is recommended to configure a Cron Job to automatically restart it every Sunday at 3:00 AM:

# Run crontab -e and add the following schedule
0 3 * * 7 /usr/bin/systemctl restart polkit

Chapter 2: Trimming Down MariaDB (MySQL)

On multi-core systems, MariaDB allocates a substantial amount of memory by default. We need to aggressively trim it for a 1GB RAM environment. Edit /etc/my.cnf.d/mariadb-server.cnf and modify the [mysqld] section as follows:

[mysqld]
# Limit the size of the InnoDB core buffer pool (most critical; usually 128M+ by default)
innodb_buffer_pool_size = 16M
innodb_log_buffer_size = 2M

# Completely disable the performance monitoring framework (a memory hog on small hosts)
performance_schema = OFF

# Limit the maximum number of connections and the thread cache
max_connections = 20
key_buffer_size = 4M
thread_cache_size = 0
table_open_cache = 64

# 【Hidden memory hog】Limit the internal cache of the Aria storage engine (often set to 128M by default)
aria_pagecache_buffer_size = 8M
join_buffer_size = 128K
read_buffer_size = 128K

After making the changes, run sudo systemctl restart mariadb for a complete restart. MariaDB's physical memory usage (RSS) should drop from 170MB+ to around 80MB.

Chapter 3: Dynamic Scheduling for PHP 8.3 and PHP-FPM

For a website that is already publicly accessible and has stable traffic, you must not use ondemand mode; otherwise, repeatedly destroying and creating processes will consume CPU. We should retain dynamic mode while reducing the process pool to the leanest practical configuration.

1. Fine-Tune the PHP-FPM Pool Configuration

Edit the corresponding website Pool configuration file (such as /etc/php-fpm.d/your_site.conf):

pm = dynamic
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 2
# 【Key to preventing leaks】Respawn the process after every 800 requests to clear accumulated garbage
pm.max_requests = 800

2. Trim OPcache Memory

Edit /etc/php.d/10-opcache.ini. Newer AlmaLinux versions allocate as much as 128MB to OPcache by default. For a clean, pure PHP custom-built system, the compiled code often uses less than 9MB in practice, so allocating 48MB is sufficient. This immediately helps the host recover 80MB of free physical memory:

opcache.enable=1
opcache.memory_consumption=48
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
# Disable the unnecessary JIT to save preallocated space
opcache.jit_buffer_size=0

Chapter 4: Frontline Edge Defense (Cloudflare)

If GA4 (Google Analytics) shows a large number of active users with an “average engagement time of 0 seconds,” it indicates that the website is being flooded by malicious data-collection crawlers and bot traffic. This traffic can pass through to and overwhelm the small host's database.

1. Enable Bot Fight Mode

After logging in to the Cloudflare dashboard, go to Security ➔ Bots and switch Bot Fight Mode to ON. This can reject invalid requests directly at Cloudflare's edge nodes, causing the MariaDB load to drop sharply within minutes.

2. Correct the Real IP for Pure PHP Systems

After enabling the Cloudflare Proxy, system logs and Fail2ban cannot identify the real attacker's IP address. Be sure to add the following IP correction code at the very top of the core bootstrap file in the PHP project (such as index.php):

if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) {
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];
}

🏁 Final Optimization Results

With the adjustments above, under the same tens-of-thousands-of-users traffic conditions, the system's available memory successfully recovers from the brink of a crash and remains at a safe, comfortable level of 334 MiB. Linux's buff/cache can also make full use of the remaining space for high-speed caching. This server architecture combines performance, defense, and extreme minimalism, proving that even a 1GB RAM host can reliably handle the demands of commercial operations when properly tuned.