修正 SLES 系統升級期間出現的「無法分配記憶體」錯誤

SLES 升級似乎正在進行中，但隨後終端、安裝程式或遷移日誌報告「無法分配記憶體」。該訊息本身並不能證明伺服器需要更多物理記憶體。故障可能源自於記憶體壓力、虛擬機器或服務限制、交換空間缺失或無法使用，或升級環境本身的問題。首先要確定是哪個進程和哪個升級階段導致了該訊息；安全的修復方法取決於此細節。

版本很重要。截至 2026 年 10 月，SUSE 的 SLES 16.0 主版本升級指南描述了一種發行版遷移系統，該系統會啟動一個專用的即時升級鏡像；而 SLES 15 服務包遷移則使用已建立的 YaST 或 Zypper 遷移工作流程。切勿在未檢視您所使用版本的升級流程的情況下，將用於線上服務包遷移的修復程式套用至主版本升級。 SUSE 在其SLES 16 升級指南中記錄了目前的 SLES 16 升級路徑。

1. 在做出任何改變之前，先確定失敗的階段。

記錄完整的錯誤訊息、時間戳記、出現錯誤的命令或螢幕，以及系統是否已重新啟動進入安裝程式或遷移映像。 「無法分配記憶體」是一個常見的作業系統錯誤，因此錯誤訊息周圍的內容通常比錯誤本身更有幫助。

• 在軟體包事務開始之前：註冊、儲存庫、遷移準備或安裝程式程序可能發生故障。請檢查系統和進程內存，然後查看相關服務或遷移日誌。
• 在安裝或卸載軟體包期間： Zypper 和 RPM 可能已經更改了系統。即使進度緩慢，也不要終止進程、重新啟動系統或啟動第二個軟體套件管理器。請檢查控制台和日誌，並等待支援的遷移過程完成或達到明確的失敗狀態。
• 重新啟動進入升級鏡像後：進程可能會運行在與原始作業系統不同的資源環境。重新啟動前可見的交換空間並不能證明昇級鏡像可以使用它。

SUSE 的 SLES 16 遷移流程包括準備遷移環境、掛載檔案系統、設定網路、準備 Zypper、升級軟體套件、更新引導程式以及重新啟動。指南指出，升級開始前發生的錯誤會將系統恢復到初始狀態；但這並不意味著軟體包替換過程中的每個錯誤都是無害的。請保留日誌，並在確定哪個階段發生故障之前避免手動恢復。

2. 檢查 RAM、交換空間和最近的核心訊息

如果原始 SLES 系統仍在運行，或者您已進入復原 shell，請先進行唯讀檢查：

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

free -h匯總記憶體和交換空間使用情況。請專注於可用記憶體和已使用交換空間，而不僅僅是「可用」列：Linux 會將原本閒置的 RAM 用於快取。vmstat這有助於顯示機器是否持續進行頁面交換。進程清單可以揭示升級期間資料庫、Java 服務、備份或其他工作負載所佔用的記憶體。

查看錯誤發生時間附近的內核記憶體溢位 (OOM) 記錄：

sudo journalctl -k --since "30 minutes ago" |
  grep -i -E 'out of memory|oom|killed process'

如果錯誤發生在較早的時間點，請變更時間視窗。核心訊息中如果提及已終止的進程，則表示發生了記憶體不足事件；但沒有符合的行並不能排除所有記憶體分配失敗的可能性。如果升級是在獨立的生產環境中進行的，請在日誌可用時檢查該環境的日誌，而不僅依賴舊系統的日誌。

此外，也要檢查虛擬機器、容器或 systemd 單元是否設定了記憶體上限。虛擬機可能在宿主機上擁有可用內存，但仍可能達到其自身配置的內存限制。在 SLES 16 中，SUSE 將 cgroups v2 指定為預設的資源控制層級，並解釋說 systemd 可以套用資源限制。請檢查相關的虛擬機器配置或服務MemoryMax設置，而不是隨意提高全域核心限制。請參閱 SUSE 的SLES 16 核心控制組指南。

3. 減少競爭性記憶體使用，僅在安全點重試。

如果測量結果顯示某個工作負載佔用了大部分可用內存，請安排維護窗口，並在重試之前乾淨地停止非必要服務。例如，記憶體密集型應用程式工作進程、分析作業、測試資料庫和備份進程。切勿在生產主機上盲目停止儲存、叢集或應用程式服務；請使用應用程式文件中記錄的關閉流程，並確認停止服務不會中斷使用者或復原任務。

對於虛擬機，請將虛擬機器配置的記憶體與宿主機容量以及其他虛擬機的當前需求進行比較。如果虛擬機器記憶體不足，請使用虛擬機器管理程式支援的方法增加其分配的記憶體。記憶體是否支援熱添加取決於虛擬機器管理程式、虛擬機器配置和工作負載；如果需要，請規劃重新啟動。在公有雲中，請驗證實例大小以及任何提供者特定的記憶體限制。

如果機器擁有充足的可用記憶體且沒有記憶體溢位 (OOM) 記錄，但該訊息仍然存在，請檢查進程限制。對於仍在運行的進程，請/proc/PID/limits使用其實際進程 ID 進行檢查。對於 systemd 管理的升級助手，請檢查該單元的資源設定。即使主機有可用內存，限制也可能限制某個進程。只有當您能夠確定適用的設定並了解其影響時，才應更改限制。

解決已識別的限制後，請僅透過適用於您的 SLES 版本和升級路徑的升級方法來恢復或重試。對於 SLES 15 服務包遷移，請使用已記錄的 YaST 或 Zypper 遷移工作流程。對於 SLES 16 主版本遷移，請遵循 SLES 16 發行版遷移流程。 SUSE 的 SLES 15 SP7 指南在其線上升級文件中解釋了服務包工作流程和支援的回溯先決條件。

4. 謹慎考慮換位；不要盲目使用。

額外的交換空間可以在工作負載能夠進行記憶體分頁時為系統提供更多虛擬記憶體餘量，但其速度遠低於 RAM。如果機器已經大量使用交換空間，增加更多交換空間可能會導致升級速度極慢，而無法解決虛擬機器容量不足或孤立進程限制的問題。首先，請確認是否有交換空間以及它是否正在使用swapon --show。free -h

如果需要新增交換分割區，請依照 SUSE 針對您的 SLES 版本和檔案系統提供的步驟操作。尤其要注意 Btrfs 檔案系統：SUSE 文件中對 Btrfs 上的交換檔案有諸多限制，並指出當來源子磁碟區中的交換檔案處於活動狀態時，無法建立快照。由於 SLES 通常依賴 Snapper 快照進行系統恢復，因此在升級期間，請勿在已建立快照的根子磁碟區上建立和啟動通用交換檔案。建議在檢查儲存佈局和復原計畫後，新增 RAM 或使用配置正確的交換分區或受支援的位置。有關檔案系統的具體細節，請參閱 SUSE 的SLES 15 SP7 儲存指南。

請勿立即變更vm.overcommit_memory或停用 OOM killer，也不要執行任意清理指令。這些操作可能會掩蓋問題症狀、導致工作負荷不穩定或增加恢復難度。請先收集證據，如果日誌指向特定的記憶體配置，請參考 SUSE 或應用程式供應商提供的特定設定指南。

5. 如果升級在軟體包更改開始後停止，則進行恢復

在決定重新運行升級之前，請確定軟體包管理器是否仍然處於活動狀態，以及遷移工具是否報告了最終失敗。如果升級在軟體包變更開始後停止，請儲存完整的日誌輸出並查閱特定版本的復原文件。請勿同時執行zypper dupYaSTzypper migration遷移和 RPM 指令。

在 SLES 15 SP7 中，SUSE 文件介紹了當根檔案系統為 Btrfs 且啟用 Snapper 快照時如何回滾服務套件。回滾過程需要識別並測試遷移前的快照，然後永久回滾；但這並非適用於所有升級錯誤的通用解決方案。 SLES 16 的主版本遷移遵循不同的工作流程，因此請使用其當前的升級和復原說明，而不要想當然地認為 SLES 15 的步驟同樣適用。如果系統對業務至關重要、沒有經過測試的備份，或在軟體包替換過程中遷移失敗，請在嘗試手動修復軟體包之前提交 SUSE 支援案例。

6. 恢復正常運作前，請先驗證系統。

升級完成後，伺服器正常啟動，請驗證作業系統版本和註冊訊息，然後檢查軟體包一致性以及最初暴露問題的工作負載：

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper verify
free -h
swapon --show

使用您的 SLES 版本支援的 package-verification 指令；如果該zypper verify指令在您的版本中不可用或行為異常，請查閱zypper help該版本的管理指南。檢查應用程式和核心日誌中是否有新錯誤，確認所需服務運作正常，並在負載復原期間監控記憶體和交換空間的使用情況。在維護視窗關閉之前，請確認已安裝受支援的升級目標，且伺服器的註冊和儲存庫處於預期狀態。

成功修復不僅僅意味著錯誤訊息消失：SLES 遷移使用受支援的路徑完成，機器啟動到預期版本，軟體包和註冊資訊檢出正常，並且正常的工作負載運行不會重複出現記憶體溢位 (OOM) 事件。如果即使記憶體壓力低、交換空間充足且沒有資源限制，仍然出現「無法分配記憶體」的錯誤，請保留詳細的日誌和進程資訊——這些線索有助於區分升級缺陷和容量問題。