在重試之前追蹤 SLES 升級記憶體錯誤

如果在升級過程中 SLES 報告“無法分配記憶體”，請先檢查核心是否記錄了記憶體不足事件，以及 RAM 或交換空間是否已耗盡。暫停已知的非必要工作負載或增加虛擬機器分配的內存，僅在確認內存壓力後才可執行此操作，然後驗證 Zypper 和 RPM 是否已停止運行，之後再恢復原始升級過程。

假設一個 SLES 15 虛擬機，管理員在執行大型批次作業的同時啟動了已排程的軟體包更新。 Zypper 因記憶體分配錯誤而停止運作。以下範例僅供參考，並非真實事件或測試報告；請在選擇解決方案之前，請使用以下命令在您自己的主機上收集證據。

1. 檢查伺服器是否仍在升級

即使 SSH 會話顯示錯誤，也不要重新啟動系統、終止軟體包進程或執行第二個升級命令。請重新連線並檢查是否有 Zypper 或 RPM 進程在運作：

pgrep -a 'zypper|rpm'

如果軟體包進程仍在運行，請稍等片刻，然後檢查其輸出或日誌。在軟體包操作可能正在進行時，請勿刪除 Zypper 鎖定檔案。如果沒有進程正在運行，請保留完整的錯誤文字並記錄其發生時間；該時間戳有助於關聯內核日誌和軟體包日誌。

2. 確認或排除記憶壓力

收集目前 RAM 和交換空間快照：

free -h
swapon --show
vmstat 1 5

在 ` <path>` 中free -h，檢查available列，而不僅僅是標記為 `<value>` 的值free；Linux 也使用 RAM 作為快取。 `<path>`會報告是否有交換空間以及swapon --show使用了多少空間。在 ` <path>` 中vmstat，最近幾行中重複出現的非零值表示正在使用交換空間；第一行是自啟動以來的平均值，因此請專注於後面的行。siso

然後查找故障發生前後出現的內核記憶體不足 (OOM) 終止錯誤，並閱讀 Zypper 日誌：

sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'
sudo tail -n 80 /var/log/zypper.log

指向 RPM、Zypper 或其他進程的 OOM 終止記錄有助於診斷真正的記憶體壓力問題。僅憑「可用」RAM 不足不足以確診：快取可能已被回收，且該訊息也可能是由進程或服務的記憶體限制引起的。如果沒有核心 OOM 條目，請在增加主機記憶體之前，檢查失敗命令的限制以及任何 systemd 或容器的記憶體上限。僅憑「無法分配記憶體」此資訊無法確定確切原因。

3. 重試前先減輕壓力

返回假設的虛擬機器。如果批次作業佔用大量內存，且系統顯示持續的交換活動或核心內存不足終止（OOM kill），請使用應用程式支援的暫停或停止程式。切勿在未執行操作員的關閉步驟的情況下終止資料庫、SAP 工作負載或其他有狀態服務。工作負載暫停後，請再次檢查 RAM 和交換空間。

如果在正常維護期間虛擬機器記憶體不足，請透過支援的虛擬機器管理程式或雲端控制平面增加其分配的 RAM，然後確認作業系統已識別到新的記憶體容量。增加交換空間可以提供臨時的記憶體空間，但速度比 RAM 慢，並且無法解決持續的記憶體需求問題。 SLES 儲存佈局至關重要：例如，SUSE 文件中明確規定了 Btrfs 檔案系統上交換文件的特定限制。除非您已檢查過檔案系統、快照和平台的要求，否則請避免在升級期間建立或調整交換空間的大小。

如果 OOM 記錄不存在，則應檢查適用於故障進程的限制。在 SLES 15 上，檢查 systemd 管理的工作負載配置的記憶體上限，並將範例單元名稱替換為受影響的服務：

sudo systemctl show example-batch.service -p MemoryMax

將該值與可用記憶體進行比較。除非同時相應地提高 cgroup 限制，否則增加虛擬機器的 RAM 並不能解決 cgroup 限制問題。在較舊的服務包中，請對照該版本的 systemd 文件確認屬性名稱。

4. 恢復先前支援的升級並進行驗證。

軟體包進程退出後，請檢查/var/log/zypper.log最後完成的操作以及任何失敗的軟體包。如果 RPM 或 Zypper 報告交易未完成，請依照 SUSE 針對該特定錯誤的復原指南進行操作，然後再重試。請勿手動刪除軟體包資料庫檔案或鎖。

使用您最初啟動的升級路徑。例行軟體包維護和服務包遷移是不同的操作：SUSE 文件zypper patch提供了安裝適用已發布補丁的說明，而服務包和主要版本升級則有其自身的支援路徑和準備工作。不要zypper dup僅僅為了臨時解決問題而切換到其他路徑。對於例行補丁運行，請先檢查交易：

sudo zypper patch --dry-run

如果試運行顯示計劃合理且記憶體穩定，請安排維護視窗並執行與原始任務對應的命令。保持 SSH 會話可用，監控進程，並在之後檢查結果：

sudo tail -n 80 /var/log/zypper.log
sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'

成功復原意味著目標軟體包或遷移已完成，Zypper 已正常退出，且運行期間未出現新的記憶體溢位 (OOM) 事件。如果系統可啟動，但必須回滾 SLES 服務包遷移本身，則 SUSE 文件中記錄的 Snapper 回滾僅在滿足其要求時適用，這些要求包括受支援的 Btrfs 根檔案系統和已配置的快照。請勿將回滾視為對失敗的軟體包修補程式的通用回應。

何時停止並升級

如果在記憶體壓力解除後錯誤仍然存在，軟體包進程仍然卡住，或者 RPM 資料庫報告損壞，請停止重試。請儲存 Zypper 日誌、核心日誌、產品和服務包等級以及所使用的確切命令。 SUSEsupportconfig可以收集診斷資料以建立支援案例。此處的步驟有助於區分記憶體壓力與其他分配故障；但如果沒有完整的日誌和系統配置，則無法確定特定於產品的缺陷。

有關當前 SLES 15 SP7 的詳細信息，請參閱 SUSE 的系統監控實用程式、日誌檔案參考、Zypper 管理指南、交換分區和 Btrfs 要求以及線上升級和回滾說明。命令和復原路徑可能會因 SLES 服務包、架構、檔案系統以及任務是修補還是版本遷移而異。