再試行前にSLESアップグレードのメモリエラーを追跡する

SLES がアップグレード中に「メモリを割り当てできません」と報告した場合、まずカーネルがメモリ不足イベントを記録したかどうか、また RAM またはスワップ領域が枯渇したかどうかを確認してください。負荷がかかっていることを確認した後で、既知の不要なワークロードを一時停止するか、VM に割り当てられたメモリを増やし、Zypper と RPM がアクティブでなくなったことを確認してから、元のアップグレード手順を再開してください。

架空の例： SLES 15仮想マシンで、管理者が大規模なバッチジョブの実行中にスケジュールされたパッケージ更新を開始したとします。Zypperはメモリ割り当てエラーで停止します。以下の例は説明のためのものであり、実際のインシデントやテストの報告ではありません。対策を選択する前に、コマンドを使用してご自身のホストで証拠を収集してください。

1. サーバーがまだアップグレード中かどうか確認してください。

SSHセッションでエラーが表示されたからといって、再起動したり、パッケージプロセスを強制終了したり、2回目のアップグレードコマンドを実行したりしないでください。別のセッションで再接続し、アクティブなZypperまたはRPMプロセスを確認してください。

pgrep -a 'zypper|rpm'

パッケージ処理がまだ実行中の場合は、しばらく待ってから出力またはログを確認してください。パッケージ操作がアクティブな可能性がある間は、Zypperのロックファイルを削除しないでください。プロセスが実行されていない場合は、正確なエラーメッセージと発生日時を記録してください。そのタイムスタンプは、カーネルログとパッケージログの関連付けに役立ちます。

2. メモリプレッシャーの有無を確認する

現在のRAMとスワップのスナップショットを取得します。

free -h
swapon --show
vmstat 1 5

ではfree -h、 とavailableマークされた量だけでなく、列も確認してくださいfree。Linux はキャッシュに RAM も使用します。swapon --showは、スワップが存在するかどうかと、どれだけ使用されているかを示します。 ではvmstat、最近の行でゼロ以外siの とsoの値が繰り返されている場合は、アクティブなスワッピングを示しています。最初の行は起動からの平均値なので、後の行に注目してください。

次に、障害発生箇所付近でカーネルのメモリ不足（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-killレコードは、真のメモリ不足の診断をサポートします。「空き」RAMが少ないだけでは診断できません。キャッシュは解放される可能性があり、メッセージはプロセスまたはサービスのメモリ制限によって発生することもあります。カーネルOOMエントリが表示されない場合は、ホストメモリを追加する前に、失敗したコマンドの制限とsystemdまたはコンテナのメモリ上限を確認してください。「メモリを割り当てできません」というフレーズだけでは、正確な原因を特定することはできません。

3. 再試行する前に圧力を下げてください

仮想VMに戻ります。バッチジョブがメモリを消費し、システムが継続的なスワップアクティビティまたはカーネルのOOMキルを示している場合は、アプリケーションでサポートされている一時停止または停止手順を使用してください。オペレーターのシャットダウン手順なしに、データベース、SAPワークロード、またはその他のステートフルサービスを終了しないでください。ワークロードを一時停止した後、RAMとスワップを再度確認してください。

通常のメンテナンス中にゲストOSのメモリが不足する場合は、サポートされているハイパーバイザーまたはクラウドコントロールプレーンを使用して割り当てられているRAMを増やし、オペレーティングシステムが新しいメモリ量を認識していることを確認してください。スワップ領域を追加することで一時的な余裕は確保できますが、RAMよりも処理速度が遅く、持続的なメモリ需要を解消することはできません。SLESのストレージレイアウトは重要です。たとえば、SUSEはBtrfs上のスワップファイルに関する特定の制約を文書化しています。ファイルシステム、スナップショット、およびプラットフォームの要件を確認しない限り、アップグレード中にスワップ領域を作成またはサイズ変更することは避けてください。

OOMレコードが存在しない場合は、代わりに障害が発生したプロセスに適用される制限を調査してください。SLES 15では、systemdで管理されているワークロードの構成済みメモリ上限を調べ、サンプルユニット名を影響を受けるサービスに置き換えてください。

sudo systemctl show example-batch.service -p MemoryMax

その値を利用可能なメモリと比較してください。cgroup の制限は、VM の RAM を増やしても、制限値自体が適切に引き上げられない限り修正されません。古いサービス パックの場合は、そのリリースの 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 ログ、カーネルジャーナル、製品およびサービスパックレベル、使用した正確なコマンドを保存してください。SUSE は、supportconfigサポートケースのために診断データを収集できます。ここでの手順は、メモリ負荷とその他の割り当てエラーを区別するのに役立ちますが、完全なログとシステム構成がないと、製品固有の欠陥を特定することはできません。

SLES 15 SP7 の詳細については、SUSE のシステム監視ユーティリティ、ログファイルリファレンス、Zypper 管理ガイド、スワップおよび Btrfs の要件、オンラインアップグレードおよびロールバック手順を参照してください。コマンドと復旧手順は、SLES サービスパック、アーキテクチャ、ファイルシステム、およびパッチ適用かリリース移行かによって異なる場合があります。