1GB RAM 小主機終極榨乾指南：AlmaLinux 10.2 / Webmin / 純 PHP 與 MariaDB 輕量化實戰

在平價雲端 VPS（如 1GB RAM、雙核 Intel vCPU）的環境下，許多開源管理面板（如 Webmin/Virtualmin）與底層資料庫預設的組態都過於臃腫。特別是面對對外公開、日均千人（7天達3萬活躍）的正式網站，若不進行微調，極易觸發 Linux 的 OOM (Out of Memory) 機制導致服務崩潰。

本文將完整記錄如何透過「系統層、資料庫層、應用程式層、網路防禦層」四維一體的極致優化，將可用實體記憶體拉回 330MB+ 的安全水位，並徹底降載 MariaDB。

---

第一章：底層作業系統的斷捨離與防線

1. 建立 2GB Swap 虛擬記憶體緩衝

當實體記憶體突發性不足時，Swap 能提供關鍵的墊底保護，防止 OOM 崩潰。

# 建立 2GB 的空白檔案
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 設定開機自動掛載
echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

2. 強制封鎖（Mask）未使用的背景服務

如果網站不需要對外發信，僅在 UI 關閉服務是不夠的，底層 postfix 仍會被系統依賴喚醒。必須使用 mask 徹底鎖死：

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

3. 解除 polkitd 的記憶體洩漏隱憂

polkitd 權限守護進程在長時間運行後容易累積快取垃圾（可能吃掉高達 66MB）。由於重啟它完全不影響網頁運行，建議設定 Cron Job 排程，讓系統每週日凌晨 3:00 自動將其重啟轉生：

# 執行 crontab -e 加入以下排程
0 3 * * 7 /usr/bin/systemctl restart polkit

---

第二章：MariaDB (MySQL) 的減肥手術

在多核心系統中，MariaDB 預設會宣告極大的記憶體空間。我們要針對 1GB RAM 環境進行硬性閹割。請編輯 /etc/my.cnf.d/mariadb-server.cnf，在 [mysqld] 區塊下修正：

[mysqld]
# 限制 InnoDB 核心緩衝池大小（最關鍵，預設通常高達 128M+）
innodb_buffer_pool_size = 16M
innodb_log_buffer_size = 2M

# 徹底關閉性能監控架構（這功能在小主機上是記憶體小偷）
performance_schema = OFF

# 限縮最大連線與執行緒快取
max_connections = 20
key_buffer_size = 4M
thread_cache_size = 0
table_open_cache = 64

# 【隱形大戶】限制 Aria 儲存引擎的內部快取（預設常給到 128M）
aria_pagecache_buffer_size = 8M
join_buffer_size = 128K
read_buffer_size = 128K

修改後執行 sudo systemctl restart mariadb 徹底重啟，MariaDB 實體記憶體佔用（RSS）將成功從 170MB+ 暴跌至 80MB 左右。

---

第三章：PHP 8.3 與 PHP-FPM 的動態排班學

對於已經對外公開且具備穩定流量的網站，絕不能使用 ondemand 模式，否則頻繁銷毀與建立進程會耗盡 CPU。我們應維持 dynamic 模式，但將編制縮減到最精實。

1. 微調 PHP-FPM Pool 設定

編輯對應的網站 Pool 設定檔（如 /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
# 【防洩漏關鍵】每處理完 800 次請求就讓進程轉生，清空垃圾
pm.max_requests = 800

2. 精簡 OPcache 記憶體

編輯 /etc/php.d/10-opcache.ini。新版 AlmaLinux 預設會給 OPcache 高達 128MB 的額度。對於結構乾淨的純 PHP 自研系統，實際編譯後往往用不到 9MB，改分配 48MB 即可，這能立刻幫主機逼出 80MB 的實體空閒記憶體：

opcache.enable=1
opcache.memory_consumption=48
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
# 關閉不需要的 JIT 以節省預分配空間
opcache.jit_buffer_size=0

---

第四章：最前線的邊緣防禦 (Cloudflare)

如果 GA4（Google Analytics）上出現大量「平均參與時間 0 秒」的活躍使用者，代表網站正遭受網路惡意採集爬蟲與機器人流量的洗劫。這些流量會穿透並壓垮小主機的資料庫。

1. 開啟 Bot Fight Mode

登入 Cloudflare 後台，進入 Security ➔ Bots，將 Bot Fight Mode 切換為 ON。這能在雲端節點直接彈開無效請求，讓 MariaDB 的負載在幾分鐘內瞬間降載。

2. 純 PHP 系統的真實 IP 修正

開啟 Cloudflare Proxy 後，系統日誌與 Fail2ban 會無法抓到真實攻擊者 IP。請務必在 PHP 專案最核心的引導檔案（如 index.php）最頂端加上 IP 修正代碼：

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

---

🏁 最終優化成果結算

透過上述調整，在相同萬人流量環境下，系統的 available（可用記憶體）成功從崩潰邊緣拉回並常駐在 334 MiB 的安全寬鬆水位，Linux 的 buff/cache 也能充分利用剩餘空間進行高速快取。這套兼具性能、防禦與極致精簡的伺服器架構，證明了即便是 1GB RAM 的小主機，只要調教得當，依然能穩健扛起商業營運的重任。