内容

概要

vEdge 5000/2000/1000/100BおよびvEdgeクラウドプラットフォームで報告されるCPU高使用率について

説明

fp-umプロセスによるCPU高使用率

結論

概要

このドキュメントでは、vEdge 5000/2000/1000/100BおよびvEdge CloudプラットフォームのvManageで高いCPU使用率が報告される理由について説明します。

vEdge 5000/2000/1000/100BおよびvEdgeクラウドプラットフォームで報告されるCPU高使用率について

17.2.x以降のリリースでは、vEdgeおよびvEdgeクラウドプラットフォームのCPUおよびメモリの消費量が増加することが確認できます。これは、特定のデバイスのvManageダッシュボードで確認できます。場合によっては、vManageのアラートと警告の数が増加します。

説明

デバイスが通常、低、または負荷なしで正常に動作すると報告される高CPU使用率の理由は、使用率の計算に使用される式の変更によるものです。17.2リリースでは、vEdgeのshow system statusからの負荷平均に基づいてCPU使用率がが計算されます。

vManageは、デバイスのリアルタイムCPU使用率を表示します。履歴データに基づいて、1分間の平均[min1_avg]と5分間の平均[min5_avg]が取得されます。負荷平均は、定義により、使用率の計算に役立つCPUサイクルだけでなく、さまざまな要素が含まれます。  たとえば、プラットフォームにこの値を提示すると、IO待機時間、プロセス保留時間、およびその他の値が考慮されます。この場合、vShellのtopコマンドで表示されるCPU状態とCPU値の値は無視します。

実際には1分間の負荷平均であるCPU使用率が計算され、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使用率はLoad-Average / Number of Core (vCPU)に基づいて計算されます。 この例では、ノードに4つのコアがあります。すべてのコアの負荷平均を100で割る前に、負荷平均を100の係数で換算します。この値を取り出すと、最大310の値が得られます。この値を4で除算すると、リアルタイムのグラフに表示される値77777777777.5%が図に示すように、CLI出力が収集された前後にキャプチャされた情報を管理します。

システムの負荷平均とCPUコア数を調べるには、デバイスのvShellからtopの出力を調べられます。

この例では、vEdgeには4つのvCPUが含まれています。最初のコア(Cpu0)はControlに使用されます（低いユーザ使用率で確認）、残りの3つのコアはDataに使用されます。

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には1つのCPUコアしか使用できないため、ここで報告される負荷は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はpoll-modeドライバを使用するプロセスで、受信されたフレームを速やかに処理できるように、常に基になるポートにパケットを送信し、ポーリングします。アーキテクチャは、データプレーン開発キット(DPDK)フレームワークに基づく効率的なパケット処理のためにインテルによって使用されます。パケット転送はタイトなループで実装されるため、CPUは常に100 %以下のままになります。この動作は正常に行われますが、これらのCPUでは遅延は発生しません。

DPDKポーリングに関する背景情報はこちらをご覧ください。

vEdge CloudおよびvEdge 5000プラットフォームは、同じ転送アーキテクチャを使用し、この点で同じ動作を示します。上の出力から引き出されたvEdge 5000の例を示します。28個のコアがあり、そのうち2（Cpu0とCpu1）がControl(vEdge 2000など)に、26がDataに使用されます。

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%で動作するため、Load Averageは常に高くなっています。

結論

17.2.7より前の17.2.xリリースのvManageで報告されたCPU使用率は、実際のCPU使用率ではなく、負荷平均に基づいて計算されます。これにより、プラットフォームが正常、低、または実際のトラフィックやネットワークの負荷なしで正常に動作している間、報告された値を理解し、CPU高使用率に関する誤ったアラームが発生する可能性があります。

この動作は、17.2.7および18.2リリースで変更および変更され、上からのcpu_userの読み取りに基づいてCPUの読み取りを正確に行うことができます。

この問題は、17.2リリースノートにも記載されています。