vEdge 5000/2000/1000/100BおよびvEdgeクラウドプラットフォームのvManageによって報告される高いCPU使用率の理解
概要
このドキュメントでは、プラットフォームのパフォーマンスが正常であるにもかかわらず、vEdge 5000/2000/1000/100BおよびvEdge CloudプラットフォームのvManageで高いCPU使用率が報告され、上部に表示されているように高いCPU使用率が報告されない理由について説明します。
vEdge 5000/2000/1000/100BおよびvEdgeクラウドプラットフォームで報告される高いCPU使用率の理解
17.2.x以降のリリースでは、vEdgeおよびvEdge CloudプラットフォームのCPUとメモリの消費量が増加する傾向があります。これは、特定のデバイスのvManageダッシュボードで確認できます。場合によっては、vManageでアラートと警告の数が増えることもあります。
説明
デバイスが通常の状態、低い状態、または負荷なしで正常に動作しているときにCPU使用率が高いと報告される理由は、使用率の計算に使用される数式が変更されたためです。 17.2リリースでは、CPU使用率はvEdgeのshow system statusのLoad Averageに基づいて計算されます。
vManageは、デバイスのCPU使用率をリアルタイムで表示します。履歴データに基づいて、1分間平均[min1_avg]と5分間平均[min5_avg]を取得します。Load Averageは定義上、使用率の計算に使用されるCPUサイクルだけでなく、さまざまな要素を含みます。 たとえば、プラットフォームに対してこの値を提示すると、IO待機時間、プロセス保留時間、およびその他の値が考慮されます。この場合、vShellのtopコマンドで表示されるCPU状態とCPU値の値は無視されます。
CPU使用率（実際には1分間の負荷平均）がどのように計算され、vManageダッシュボードに表示されるかについての例を次に示します。
vEdge CLIからロードを確認すると、次のように表示されます。
vEdge# show system status | include Load Load average: 1 minute: 3.10, 5 minutes: 3.06, 15 minutes: 3.05 Load average: 1 minute: 3.12, 5 minutes: 3.07, 15 minutes: 3.06 Load average: 1 minute: 3.13, 5 minutes: 3.08, 15 minutes: 3.07
Load average: 1 minute: 3.10, 5 minutes: 3.07, 15 minutes: 3.05
この場合、CPU使用率は負荷平均/コア数(vCPU)に基づいて計算されます。 この例では、ノードに4つのコアがあります。次に、コアの数で除算する前に、負荷平均が100倍に変換されます。 すべてのコアの負荷平均を平均し、100倍すると、310以下の値になります。この値を4つの収率（CPUの77.5 %の値）で除算すると、CLI出力が収集された前後にキャプチャされたvManageのリアルタイムグラフに表示される値と一致します。
システムの負荷平均とCPUコアの数を確認するために、デバイスのvShellからtopの出力を調べることができます。
次の例では、vEdgeには4つのvCPUが含まれています。 最初のコア(Cpu0)は（低いユーザ使用率で確認できる）制御に使用され、残りの3つのコアはデータに使用されます。
top - 01:14:57 up 1 day, 3:15, 1 user, load average: 3.06, 3.06, 3.08 Tasks: 219 total, 5 running, 214 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7%us, 4.0%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 56.0%us, 44.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 54.2%us, 45.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 59.3%us, 40.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7382664k total, 2835232k used, 4547432k free, 130520k buffers Swap: 0k total, 0k used, 0k free, 587880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 978 root 20 0 3392m 664m 127m R 100 9.2 1635:21 fp-um-2 692 root 20 0 3392m 664m 127m R 100 9.2 1635:18 fp-um-1 979 root 20 0 3392m 664m 127m R 100 9.2 1634:51 fp-um-3 694 root 20 0 1908m 204m 131m S 1 2.8 15:29.95 ftmd 496 root 20 0 759m 72m 3764 S 0 1.0 1:31.50 confd
vEdge CLIからCPUの数を取得するには、次のコマンドを使用できます。
vEdge# show system status | display xml | include total_cpu
<total_cpu_count>4</total_cpu_count>
vEdge 1000上のvManageに表示される値の別の計算例を次に示します。vShellからtopを発行した後、l はすべてのコアの負荷を表示します。
top - 18:19:49 up 19 days, 1:37, 1 user, load average: 0.55, 0.71, 0.73
vEdge 1000では使用可能なCPUコアが1つしかないため、ここで報告される負荷は55 %(0.55*100)です。
fp-umプロセスによる高いCPU使用率
また、fp-umプロセスが高く実行され、最大100 %のCPUが表示されることも、上部で確認できます。これは、データプレーン処理に使用されるCPUコアで想定されます。
前述のtopコマンドから、3つのコアは100 %のCPUで動作し、1つのコアは通常の使用率を示しています。
top - 01:14:57 up 1 day, 3:15, 1 user, load average: 3.06, 3.06, 3.08 Tasks: 219 total, 5 running, 214 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7%us, 4.0%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 56.0%us, 44.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 54.2%us, 45.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 59.3%us, 40.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7382664k total, 2835232k used, 4547432k free, 130520k buffers Swap: 0k total, 0k used, 0k free, 587880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 978 root 20 0 3392m 664m 127m R 100 9.2 1635:21 fp-um-2 692 root 20 0 3392m 664m 127m R 100 9.2 1635:18 fp-um-1 979 root 20 0 3392m 664m 127m R 100 9.2 1634:51 fp-um-3 ...
この最初のコア(Cpu0)はControlに使用され、残りの3つのコアはDataに使用されます。プロセスリストからわかるように、fp-umプロセスはこれらのリソースを使用します。
fp-umは、ポールモードドライバを使用するプロセスです。これは、基盤となるポートを常時ポーリングし、受信されたフレームをただちに処理できることを意味します。 このプロセスはフォワーディングを処理し、vEdge 1000、vEdge 2000、およびvEdge 100のファストパスフォワーディングと同等です。このポーリングモードアーキテクチャは、Data Plane Development Kit(DPDK)フレームワークに基づく効率的なパケット処理のためにIntelによって使用されます。パケット転送はタイトループで実装されるため、CPUは常に100 %またはそれに近い状態を維持します。これは実行されますが、これらのCPUでは遅延が発生しません。これは、正常な動作です。
DPDKポーリングの背景情報については、こちらを参照してください。
vEdge CloudとvEdge 5000プラットフォームは同じフォワーディングアーキテクチャを使用し、この点では同じ動作を示します。次に、上部の出力から引用したvEdge 5000の例を示します。28のコアがあり、そのうち2（Cpu0とCpu1）が制御に使用され（vEdge 2000と同様）、26がデータに使用されます。
top - 02:18:30 up 1 day, 7:33, 1 user, load average: 26.24, 26.28, 26.31 Tasks: 382 total, 27 running, 355 sleeping, 0 stopped, 0 zombie Cpu0 : 0.7%us, 1.3%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.7%us, 1.3%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 79.4%us, 20.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 73.4%us, 26.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 73.4%us, 26.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu8 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu9 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu10 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu11 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu12 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu13 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu14 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu15 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu16 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu17 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu18 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu19 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu20 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu21 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu22 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu23 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu24 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu25 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu26 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu27 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32659508k total, 10877980k used, 21781528k free, 214788k buffers Swap: 0k total, 0k used, 0k free, 1039104k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2028 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-3 2029 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-4 2030 root 20 0 12.1g 668m 124m R 100 2.1 1897:12 fp-um-5 2031 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-6 2032 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-7 2034 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-9 2035 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-10 2038 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-13 2040 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-15 2041 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-16 2043 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-18 2045 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-20 2052 root 20 0 12.1g 668m 124m R 100 2.1 1897:18 fp-um-27 2033 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-8 2036 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-11 2037 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-12 2039 root 20 0 12.1g 668m 124m R 100 2.1 1897:09 fp-um-14 2042 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-17 2044 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-19 2046 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-21 2047 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-22 2048 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-23 2049 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-24 2050 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-25 2051 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-26 1419 root 20 0 116m 5732 2280 S 0 0.0 0:02.00 chmgrd 1323 root 20 0 753m 70m 3764 S 0 0.2 1:51.20 confd 1432 root 20 0 1683m 172m 134m S 0 0.5 0:58.91 fpmd
ここで、28個のプロセッサのうち26個がfp-umプロセスのために100 %で動作しているため、常に負荷平均が高くなっています。
結論
17.2.7より前の17.2.xリリースでvManageで報告されるCPU使用率は、実際のCPU使用率ではなく、負荷平均に基づいて計算されます。これにより、報告された値を理解する際に混乱が生じ、実際のトラフィック/ネットワーク負荷が正常、低負荷、またはゼロの状態でプラットフォームが正常に動作している間に、CPUの高使用に関連する誤ったアラームが発生する可能性があります。
17.2.7および18.2リリースではこの動作の変更が加えられ、topからのcpu_userの示数に基づいてCPUの示数が正確になりました。
この問題は、17.2リリースノートにも記載されています。
フィードバック