SLESシステムアップグレード中に「メモリを割り当てできません」というエラーを修正する

SLESのアップグレードは順調に進んでいるように見えますが、ターミナル、インストーラー、または移行ログに「メモリを割り当てできません」というエラーが表示されます。このメッセージだけでは、サーバーに物理RAMが不足していることを証明することはできません。エラーの原因は、メモリ不足、仮想マシンまたはサービスの制限、スワップ領域の欠落または使用不能、あるいはアップグレード環境自体にある可能性があります。まず、どのプロセスとアップグレードフェーズでこのメッセージが表示されたかを特定してください。安全な解決策は、その詳細によって異なります。

バージョンは重要です。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システムがまだ稼働している場合、またはリカバリーシェルに到達している場合は、読み取り専用のチェックから開始してください。

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 ユニットにメモリ制限が設定されているかどうかも確認してください。ゲストはホスト上で使用可能なメモリがあっても、設定された制限に達してしまう可能性があります。SUSE の SLES 16 では、cgroups v2 がデフォルトのリソース制御階層として文書化されており、systemd がリソース制限を適用できることが説明されています。グローバルなカーネル制限を無作為に引き上げるのではなく、関連する VM 構成またはサービスの設定を確認してください。SUSE のSLES 16 カーネル制御グループガイドをMemoryMax参照してください。

3. 競合するメモリ使用量を減らし、安全な時点でのみ再試行する

計測結果からワークロードが利用可能なメモリの大部分を使用していることが判明した場合は、メンテナンス期間を設定し、再試行する前に不要なサービスを正常に停止してください。例としては、メモリを大量に消費するアプリケーションワーカー、分析ジョブ、テストデータベース、バックアッププロセスなどが挙げられます。本番ホスト上でストレージ、クラスタ、またはアプリケーションサービスを無作為に停止しないでください。アプリケーションのドキュメントに記載されているシャットダウン手順に従い、停止によってユーザーや復旧タスクが中断されないことを確認してください。

仮想マシンの場合、ゲストに設定されているRAMをホストの容量および他のゲストの現在の要求と比較します。ゲストのメモリが不足している場合は、ハイパーバイザがサポートする方式を使用して割り当てメモリを増やします。メモリのホットアドが可能かどうかは、ハイパーバイザ、ゲスト構成、およびワークロードによって異なります。必要に応じて再起動を計画してください。パブリッククラウドの場合は、インスタンスサイズとプロバイダ固有のメモリ制限を確認してください。

マシンに十分な空きRAMがあり、OOMレコードも存在しないにもかかわらずメッセージが表示され続ける場合は、プロセス制限を調べてください。実行中のプロセスについては、/proc/PID/limits実際のプロセスIDを使用して確認してください。systemdで管理されているアップグレードヘルパーについては、ユニットのリソース設定を確認してください。ホストに空きメモリがあっても、制限によって1つのプロセスが制限される場合があります。制限を変更する場合は、該当する設定を特定し、その影響を理解している場合にのみ変更してください。

特定された制約に対処した後、ご使用の SLES リリースおよびアップグレード パスでサポートされているアップグレード方法のみを使用して、アップグレードを再開または再試行してください。SLES 15 サービス パックの移行には、ドキュメントに記載されている YaST または Zypper の移行ワークフローを使用してください。SLES 16 のメジャー バージョン移行には、SLES 16 ディストリビューションの移行手順に従ってください。SUSE の SLES 15 SP7 ガイドでは、オンライン アップグレード ドキュメントで、サービス パックのワークフローとサポートされているロールバックの前提条件について説明しています。

4. スワップは慎重に検討し、安易な解決策として使用しないでください。

ワークロードがメモリをページングできる場合、追加のスワップによってシステムに仮想メモリの余裕が生まれますが、RAM よりはるかに低速です。マシンがすでに大量のスワップを行っている場合、スワップを追加すると、VM のサイズ不足や分離プロセスの制限を解決せずに、アップグレードが非常に遅くなる可能性があります。まず、スワップが存在するかどうか、および で使用されているかどうかを確認してswapon --showくださいfree -h。

スワップを追加する必要がある場合は、SUSE の SLES バージョンとファイルシステムに応じた手順に従ってください。特に Btrfs には注意が必要です。SUSE は Btrfs のスワップ ファイルに関する制限事項を文書化しており、ソース サブボリューム内のスワップ ファイルがアクティブな間はスナップショットを作成できないと明記しています。SLES はシステム復旧に Snapper スナップショットを多用するため、アップグレード ウィンドウでは、スナップショットされたルート サブボリューム上に汎用スワップ ファイルを作成してアクティブ化しないでください。ストレージ レイアウトと復旧計画を確認した後、RAM を追加するか、適切に構成されたスワップ パーティションまたはサポートされている場所を使用することを推奨します。ファイルシステム固有の詳細は、SUSE のSLES 15 SP7 ストレージ ガイドを参照してください。

初期対応として、設定を変更したり、OOMキラーを無効にしたり、任意のクリーンアップコマンドを実行したりしないでくださいvm.overcommit_memory。これらの変更は症状を隠蔽したり、ワークロードを不安定にしたり、復旧を困難にしたりする可能性があります。まずは証拠を収集し、ログが特殊なメモリ構成を示している場合は、SUSEまたはアプリケーションベンダーから提供される設定固有のガイダンスに従ってください。

5. パッケージの変更開始後にアップグレードが停止した場合の復旧

アップグレードを再実行する前に、パッケージマネージャがまだアクティブかどうか、および移行ツールが最終的な失敗を報告しているかどうかを確認してください。パッケージの変更が開始された後にアップグレードが停止した場合は、完全なログ出力を保存し、リリース固有の復旧ドキュメントを確認してください。、、YaST移行、およびRPMコマンドを同時に実行しないでzypper dupくださいzypper migration。

SLES 15 SP7 では、ルート ファイルシステムが Btrfs で Snapper スナップショットが有効になっている場合、SUSE はサービス パックのロールバックについて説明しています。ロールバック手順では、移行前のスナップショットを特定してテストし、ロールバックを永続化する必要があります。これは、すべてのアップグレード エラーに対する万能の解決策ではありません。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 イベントを起こすことなく実行されることを意味します。メモリ負荷が低く、スワップ領域が十分で、リソース制限がないにもかかわらず「メモリを割り当てできません」というエラーが返される場合は、正確なログとプロセスの詳細を保持してください。これらの情報から、アップグレードの不具合と容量の問題を区別できます。