ContainerViews によりメモリが逼迫することで vCenter Server Appliance の vpxd サービスが「Panic: Memory exceeds hard limit. Panic」のエラーでクラッシュする

Products

VMware vCenter Server

Issue/Introduction

免責事項：これは英文の記事「Vpxd service in vCenter Server Appliance crashes with "Panic: Memory exceeds hard limit. Panic" due to ContainerViews clogging up memory」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

vpxd サービスが断続的にクラッシュする。
vCenter Server Appliance の vpxd サービスが起動しない。
vSphere Client へのログイン時に「このオブジェクトを表示する権限がないか、オブジェクトが削除されています。」のエラーが表示される。
vCenter Server Appliance の /storage/core 領域が vpxd-worker コアダンプファイルによって逼迫する

vCenter Server のサービスログ (/var/log/vmware/vpxd/vpxd-<数字>.log)を確認すると、下記のような backtrace が出力されている。

YYYY-MM-DDTHH:MM:SS.484Z error vpxd[08223] [Originator@6876 sub=Memory checker] Current value 11101224 exceeds hard limit 11099136. Shutting down process.
YYYY-MM-DDTHH:MM:SS.581Z panic vpxd[08223] [Originator@6876 sub=Default]
-->
--> Panic: Memory exceeds hard limit. Panic
--> Backtrace:
--> [backtrace begin] product: VMware VirtualCenter, version: 7.0.3, build: build-24026615, tag: vpxd, cpu: x86_64, os: linux, buildType: release
--> backtrace[00] libvmacore.so[0x0037DB8B]
--> backtrace[01] libvmacore.so[0x002C79C5] Vmacore::System::Stacktrace::CaptureFullWork(unsigned int)
--> backtrace[02] libvmacore.so[0x002D6C5B] Vmacore::System::SystemFactory::CreateBacktrace(Vmacore::Ref<Vmacore::System::Backtrace>&)
--> backtrace[03] libvmacore.so[0x00370CD7]
--> backtrace[04] libvmacore.so[0x00370DF3] Vmacore::PanicExit(char const*)
--> backtrace[05] libvmacore.so[0x002C7827] Vmacore::System::ResourceChecker::DoCheck()
--> backtrace[06] libvmacore.so[0x0023B390]
--> backtrace[07] libvmacore.so[0x002349E7]
--> backtrace[08] libvmacore.so[0x00239F75]
--> backtrace[09] libvmacore.so[0x003765C0]
--> backtrace[10] libpthread.so.0[0x00007F87]
--> backtrace[11] libc.so.6[0x000F36BF]
--> backtrace[12] (no module)
--> [backtrace end]

クラッシュ発生前に複数の「vim.view.ViewManager.createContainerView」タスクが記録されており、「vim.view.View.destroy」のタスク実行数と大きく乖離があるか、「vim.view.View.destroy」タスクが全く実行されていない:
```
egrep 'View.destroy|createContainerView' vpxd-???.log | awk -F " -- " '{print $4}' | sort | uniq -c
477634 vim.view.ViewManager.createContainerView
 19314 vim.view.View.destroy
```
対象環境ではモニタリングソフトなど外部アプリケーションが稼働しており、vCenter Server に様々な用途でアクセスしている。

Environment

VMware vCenter Server Appliance 7.x
VMware vCenter Server Appliance 8.x

Cause

主に次の 2 つの条件がこの事象の原因です:

過剰な数の同時セッションログイン
モニタリングや、バックアップ、オーケストレーションツールなどシステムから頻繁かつ同時にクライアントログインが行われると、vpxd-worker のメモリに大きく負荷がかかります。
そのため、時間が経つにつれプロセスに割り当てられたメモリリソースが逼迫する可能性があります。
ContainerView オブジェクトの誤った管理
ContainerView はメモリ常駐なオブジェクトであり、ESXi ホストや仮想マシン、クラスタ、データストア、ネットワーク構成など vCenter Server のインベントリコンポーネントを表します。

- これらのビューはクライアントがインベントリデータクエリを実行するとメモリ内に作成されます。
- オブジェクトのサイズは様々であり、インベントリの複雑さに応じて最小から数百メガバイトまで変化します。
- いくつかの ContainerViews は継続して存在するよう設計されておりますが、一時的なビューは vim.view.View.destroy によって明示的に破棄される必要があります。
- 使用されていないビューが破棄されないとメモリが肥大化し、vpxd-worker プロセスの負荷を増加させます。

Resolution

この事象を解消するには以下のコマンドより何によって ContainerViews が作成されているかを確認します:

# zcat vpxd-profiler*.gz |grep SessionStats | grep Container | cut -d '/' -f5-10 | sort | uniq -c | sort -nr

上記コマンドの実行結果は以下のように表示されます:

  128 Id='52d6####-####-####-####-######e656c3'/Username='com.vmware.vcIntegrity'/ClientIP='127.0.0.1'/SessionView/Container/total 553
  128 Id='52c5####-####-####-####-######46dc12'/Username='VSPHERE.LOCAL\vpxd-extension-d557####-####-####-######b90a4e'/ClientIP='127.0.0.1'/SessionView/Container/total 32
  128 Id='52c4####-####-####-####-######895e4f'/Username='VSPHERE.LOCAL\Administrator'/ClientIP='10.x.y.zz'/SessionView/Container/total 123
  128 Id='522c####-####-####-####-######47e689'/Username='VirtualCenter'/ClientIP='127.0.0.1'/SessionView/Container/total 68
  128 Id='5219####-####-####-####-######646f1f'/Username='com.vmware.vsan.health'/ClientIP='127.0.0.1'/SessionView/Container/total 73
  127 Id='5220####-####-####-####-######59e190'/Username='VSPHERE.LOCAL\vpxd-extension-d557####-####-####-######b90a4e'/ClientIP='127.0.0.1'/SessionView/Container/total 534
  125 Id='52f6####-####-####-####-######b54da5'/Username='VSPHERE.LOCAL\Administrator'/ClientIP='10.x.10.zz'/SessionView/Container/total 471
   37 Id='5274####-####-####-####-######073eaf'/Username='<external_domain>\<account>'/ClientIP='10.x.10.z'/SessionView/Container/total 531
   16 Id='521d####-####-####-####-######c26d37'/Username='<external_domain>\<account>'/ClientIP='10.x.10.z'/SessionView/Container/total 502
    3 Id='5274####-####-####-####-######073eaf'/Username='<external_domain>\<account>'/ClientIP='10.x.10.z'/SessionView/Container/total 529

クライアント IP が 127.0.0.1 のセッションは vCenter Server のコンポーネントからのものであるため、通常は無視して問題ありません。
その他のセッションについては上記の実行結果内にあるセッション ID (例: Id='52d6####-####-####-####-######e656c3') を使用し、作成処理数と破棄処理数を比較してソースが一時的なビューの破棄を実行しているか確認します。

# zcat $(ls -1 vpxd*.gz | grep -v profiler) | grep <session_Id> | egrep "ContainerView|View.destroy" | awk -F " -- " '{print $4}' | sort | uniq -c

例:

zcat $(ls -1 vpxd*.gz | grep -v profiler) | grep 52c4####-####-####-####-######895e4f | egrep "ContainerView|View.destroy" | awk -F " -- " '{print $4}' | sort | uniq -c
  13143 vim.view.ViewManager.createContainerView
  13142 vim.view.View.destroy

上記の例ではセッションの作成元が正常にビューの破棄を実施しています。
ただ、以下の表示のように vim.view.View.destroy 処理の回数が vim.view.ViewManager.createContainerView の回数よりも圧倒的に少ない場合や、vim.view.View.destroy が表示されない場合には、セッション作成元はビューを正常に破棄していません:

zcat $(ls -1 vpxd*.gz | grep -v profiler) | grep 52f6####-####-####-####-######b54da5 | egrep "ContainerView|View.destroy" | awk -F " -- " '{print $4}' | sort | uniq -c
  1465 vim.view.ViewManager.createContainerView

特定のセッション作成元に対して破棄が正常に実行されていない場合、vpxd のクラッシュを回避するには、セッション作成元の IP アドレスを持つアプリケーションを特定し、対象アプリケーション側で vpxd へのアクセスを一時的に停止してください。
その後、問題の解決のために対象アプリケーションベンダへお問い合わせください。

Additional Information

詳細については次の API ドキュメントを確認してください。https://developer.broadcom.com/xapis/virtual-infrastructure-json-api/latest/sdk/vim25/release/ViewManager/moId/CreateContainerView/post/