在低記憶體 VPS 上執行 Debian 12 而不會出現 OOM 崩潰導致 MySQL 宕機的情況。

低記憶體的VPS可以運行Debian 12和資料庫，但穩定性取決於整體工作負載，而不僅僅是MySQL配置的快取。當可用記憶體耗盡時，Linux可能會觸發記憶體不足（OOM）終止機制，終止進程以保護系統其餘部分。如果被終止的進程是資料庫，則症狀可能表現為隨機崩潰。實際目標是防止持續的記憶體壓力，並確認核心實際終止的是哪個進程；沒有任何調優設定可以保證OOM事件永遠不會發生。

Debian 12 運行的是 MySQL 還是 MariaDB？

更改伺服器配置前請先檢查伺服器。 Debian 12 (Bookworm) 預設使用 MariaDB default-mysql-server；Oracle MySQL 需要單獨安裝。 Debian 的軟體包資訊顯示 MariaDB 是該元軟體包的伺服器相依性。運行：

mariadb --version
mysql --version
dpkg-query -W -f='${Package} ${Version}\n' mariadb-server mysql-community-server 2>/dev/null

只有在已安裝的服務是 MariaDB 時，才使用以下 MariaDB 說明。 Oracle MySQL 在許多情況下使用外觀相似的選項名稱，但套件佈局、服務名稱、可用變數和預設值可能有所不同。請查閱手冊以了解已安裝的特定 MySQL 版本。

主要參考資料：Debian Bookworm 的 default-mysql-server 軟體包和MySQL 8.0 記憶體使用手冊。

如何判斷是否是記憶體不足導致資料庫崩潰？

首先要區分核心記憶體不足所導致的程序終止（OOM kill）與資料庫錯誤、服務重新啟動、系統重新啟動或磁碟問題。在 Debian 系統中，journalctl讀取 systemd 的日誌。搜尋目前啟動程序並檢查 MariaDB 的服務日誌：

sudo journalctl -k -b --no-pager | grep -Ei 'out of memory|oom-kill|killed process'
sudo journalctl -u mariadb -b --no-pager -n 100
sudo systemctl status mariadb --no-pager

如果核心日誌中出現名稱mariadbd或mysqldOOM 訊息，則表示發生了記憶體終止事件。如果沒有符合的條目，請檢查服務本身的錯誤日誌以及提供者的重新啟動或監控歷史記錄。如果日誌記錄不是持久性的，則重新啟動後日誌可能無法取得；此外，託管 VPS 提供者可能僅公開主機的部分診斷資訊。

在伺服器處於典型流量狀態時（而不僅僅是空閒狀態）取得基準資料：

free -h
swapon --show
vmstat 1
ps -eo pid,comm,rss,%mem --sort=-rss | head

在日誌中vmstat，請觀察 ` siswapin`so和 `swapout` 列，以了解持續的換入和換出活動。非零的交換空間分配本身並不一定意味著存在問題；持續的換入和緩慢的反應時間表示記憶體壓力較大。 Linux 文件中將 OOM 處理作為記憶體無法充分回收時的最後手段。請參閱Linux 核心記憶體管理概念和 Debian 的journalctl 手冊。

調校前應該測量哪些指標？

記錄總記憶體使用量、當前和峰值交換空間使用量、最大的駐留進程數、資料庫連接數以及 Web 應用程式的正常峰值。資料庫與 Debian 系統、Web 伺服器、應用程式工作進程、監控代理程式和檔案系統快取共享記憶體。 VPS 的容器或 cgroup 記憶體限制可以低於主機的實體記憶體；資料庫快取的大小應根據服務可見的記憶體限制來設置，而不是更大的主機總記憶體。

對於 MariaDB，請檢查目前記憶體相關設定和連接峰值：

sudo mariadb -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size'); SHOW GLOBAL STATUS LIKE 'Max_used_connections'; SHOW GLOBAL STATUS LIKE 'Threads_connected';"

InnoDB 緩衝池快取表頁和索引頁。隨著同時工作的增加，連線數限制和查詢緩衝區會增加記憶體需求。避免將每個連接的緩衝區都乘以 1，max_connections就好像每個緩衝區都始終完全分配一樣，但務必將過高的連接數上限視為突發情況下的風險。 MariaDB 的記憶體指南建議同時調整全域快取、每個連接的緩衝區和引擎設定的大小，並特別強調了應用程式連接池。請閱讀MariaDB 的記憶體分配指南和處理過多連接的指南。

如何在小型 VPS 上合理配置 MariaDB？

每次只做一項更改，保留原始配置的副本，並在維護視窗期間測試重啟是否會影響使用者。 Debian 打包的 MariaDB 設定通常包含以下目錄下的檔案/etc/mysql/mariadb.conf.d/；編輯前請先驗證您安裝的系統上的活動包含目錄。刪除一個小的替換檔案比替換供應商的主檔案更容易：

sudo cp -a /etc/mysql/mariadb.conf.d /root/mariadb.conf.d.backup
sudoedit /etc/mysql/mariadb.conf.d/90-low-memory.cnf

對於一台擁有約 1 GiB 記憶體的共享 VPS，以下僅為謹慎的初始範例，並非通用的安全配置。請根據測得的峰值記憶體、資料庫大小、工作負載以及作業系統和應用程式剩餘的記憶體量來調整數值：

[mariadb]
innodb_buffer_pool_size = 192M
max_connections = 30
tmp_table_size = 16M
max_heap_table_size = 16M

MariaDB 在啟動時會從選項檔案讀取設定；請驗證您的版本支援的節名稱和有效值。如果此檔案載入失敗，請移除該外掛程式並查看日誌。重啟資料庫會中斷現有連接，因此請合理安排重啟時間：

sudo systemctl restart mariadb
sudo systemctl is-active mariadb
sudo journalctl -u mariadb -b --no-pager -n 80
sudo mariadb -e "SELECT @@innodb_buffer_pool_size, @@max_connections;"

評估結果時，應同時考慮穩定性和服務品質。較小的緩衝池可能會降低快取命中率並增加磁碟讀取次數。但如果緩衝池設定max_connections過低，則可能導致「連線數過多」錯誤。Max_used_connections在再次變更緩衝池大小之前，請將其與配置的限制進行比較並檢查應用程式集區的大小。如果資料庫在正常流量高峰期仍然崩潰，或者由於持續的磁碟交換導致回應時間下降，則應升級到更大的記憶體層或將資料庫與應用程式分開。

交換分區能否防止記憶體溢出崩潰？

交換空間為 Linux 提供了一個速度較慢的記憶體頁面傳輸空間，可以暫時緩解短暫的流量高峰。但它並不能增加高速內存，修復內存洩漏，也不能使配置不足的 VPS 適應持續的工作負載。頻繁使用交換空間可能會導致資料庫和應用程式無回應。在建立交換空間之前，請務必確認您的服務提供者是否支援交換文件，以及 VPS 是否有足夠的磁碟空間。

如果支持，可以如下建立 1 GiB 的交換文件。根據提供者的指導和可用磁碟空間調整檔案大小，並驗證每個命令的結果：

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

重新啟動後啟用此功能，/etc/fstab請先檢查是否有等效條目，然後再新增此項目：

/swapfile none swap sw 0 0

然後驗證文件sudo findmnt --verify --verbose並確認它出現在指定位置swapon --show。如果fallocate檔案系統不支援此操作或提供者阻止交換空間，請停止操作並使用提供者支援的流程。不要停用 OOM killer 或為 MySQL 設定過高的 OOM 保護評分：這不會佔用內存，反而可能使小型 VPS 的其他部分面臨更大的風險。

你怎麼知道這些改變奏效了？

至少觀察VPS在一個正常繁忙時段內的運作情況。有效的結果通常具有以下幾個特徵：

在先前觸發該事件的工作負載期間，沒有出現新的核心 OOM 終止條目。
MariaDB 保持運作狀態，重新啟動次數沒有意外增加。
vmstat 1在正常流量下不會顯示連續的換入和換出。
應用程式回應依然靈敏，資料庫連線峰值保持在新上限以下，且未出現連線錯誤。
備份已完成，資料庫查詢繼續滿足應用程式可接受的延遲要求。

不要將「服務啟動」作為唯一的成功標準。即使設定能夠維持 MariaDB 的運行，但會導致系統頻繁進行交換，也無法解決根本的容量問題。同樣，一天的平靜期並不能驗證尚未執行的月度導入、備份、流量高峰或批次作業是否成功。

什麼時候調校不再是正確的解決方法？

如果經過合理的快取和並發調整後記憶體仍然緊張，交換活動持續不斷，查詢延遲變得無法接受，或者應用程式反覆達到新的連接數限制，則應選擇更大的 VPS 或將工作負載分開。資料庫大小也很重要：過小的緩衝池雖然可以避免記憶體峰值，但卻會使磁碟 I/O 成為新的瓶頸。如果應用程式和資料庫都出現尖銳但可預測的峰值，首先要確定應用程式是否開啟了過多的連線或同時執行了記憶體密集作業。

如果使用的是 Oracle MySQL 而不是 Debian 預設的 MariaDB，請在應用這些範例之前，先對照伺服器本身的版本化手冊確認服務名稱、選項檔案路徑和記憶體變數。無論使用哪種資料庫，都應保留已測試的備份，並每次只更改一個變數。可靠的結果並非保證 Linux 永遠不會觸發記憶體溢位 (OOM) 處理；而是證明 VPS 有足夠的記憶體餘裕來應對其真正的峰值工作負載，並且 MySQL 或 MariaDB 不再是反覆出現記憶體溢位問題的資料庫。

其他主要參考資料：MariaDB 的啟動故障排除指南（其中指出伺服器還需要記憶體用於其他引擎、每個連接的緩衝區和作業系統）以及MySQL 8.0 參考手冊。