高いデータプレーンのトラブルシューティング方法 CPU

541958

Created On 09/25/18 18:55 PM - Last Modified 03/26/21 16:40 PM

Symptom

A 多数の要因により、データプレーンのCPUが急増したり、継続的に高いパフォーマンスが発生したりすることがあります: 新しいサービスやリソースの実装による急激な増加、または接続されたネットワーク、セグメント、ホストの追加による時間の経過に伴う蓄積。これらの要因などにより、パケットレート、パケットバッファ使用率、またはデータプレーンが臨界レベルに到達する 1 秒あたりの接続数が膨大に増加する可能性があります CPU 。

高いデータプレーンのトラブルシューティングを学ぶ CPU 。この記事では、データプレーンの実際の負荷を確認し、ネットワークに影響を及ぼす可能性を判断する方法をいくつか紹介します。

高いデータプレーンの影響を理解 CPU することは重要です:データプレーン CPU の使用率が高い場合、懸念の直接的な原因は表示されませんが、何が原因で高 CPU く、起こり得る結果を認識することは、適切な対応に役立ちます。

アクションを実行する前に特定する必要があるいくつかの要因:

影響を受けるトラフィックの一部、すべて、またはまったくない firewall トラフィックですか?
ユーザー、待ち時間が発生している場合は待機時間に影響を与えるだけで、特定のアプリケーションまたはすべてのトラフィック.
問題が報告されている場合、これらのレポートと一致特定ピーク時間帯、定期的な間隔で、または全くランダムな瞬間にですか。

最初の手順は、パフォーマンスの問題が発生している場所を特定することです。

データプレーン ( DP ) CPU
パケットバッファ
セッション
管理プレーン MP ( )

Resolution

高いデータプレーンを識別する方法 CPU

お客様がパフォーマンスの問題を報告した場合は、問題が発生している間に技術サポートファイルを生成します。 dp-monitor ログで ---panio"文字列を探すか (この情報は 10 分ごとにログに記録されます)、リソース使用状況を表示するには、リソースモニターの実行を示すコマンド CLI を実行 DP します。

リソースモニターを実行中のショー

このコマンドを使用して、データプレーンの使用状況を確認できます CPU 。確認したい期間を反映するために演算子を追加します。

「秒」は、1 秒単位での使用量の最後の 60 秒 CPU を示します。
'分': のように分単位で最後の 60 分間を示しています.
すべてのビューを 1 つに表示されます時間演算子を使用しない場合長い出力

>は、1
日あたり>監視統計の実行> 1
時間あたりのモニタリング統計
>、1 分単位 >のモニタリング統計>、1
分あたりの監視統計
>週単位のモニター統計>秒単位のモニタリング統計
を表示します。

実際の出力はこれに似ていますが、システムのデータプレーンとコアの量によって若干異なる場合があります。

実行中のリソースモニタを表示>

DP dp0

リソース監視 (毎秒) のサンプリングデータ:

この最初のセクションでは、 CPU データプレーンで実行されているプロセスごとの使用率を示します。

CPU グループ別負荷サンプリング:
flow_lookup : 0% flow_fastpath :
0% flow_slowpath :

0% flow_forwarding :
0% flow_mgmt : 0% flow_ctrl : 0% nac_result
:

0% flow_np : 0%
dfa_result flow_np : 0% module_internal :
0% aho_result :
0% zip_result :

0% pktlog_forwarding :
0%
flow_host : 1%

出力のこの部分は、データプレーン上の個々のコアの使用率を示します。
75%を定期的に上回る多くのコアは調査を保証します。

CPU負荷 (%)最後の60秒の間に:
コア0 0 1 2 3 5 6 7 8 8 9 9 10 11
0 39 47 38 46 76 73 83 73 83 82
82 73 82 89 82
0 39 46 39 45 7 3 81 73 83 83 88 83
0 38 52 37 50 50 71 81 71 80 82 98 82
0 40 46 39 45 74 84 74 74 8
4 83 90 83
0 39 46 38 45 72 82 72 72 81 88 81
0 42 52 41 50 75 86 75 86 84 91 84
0 42 76 76 79 85 75 10075 1001001 00 85 >>>は、実際の高いCPU
0 44 51 43 50 78 85 78 86 86 91 86
0 42 51 41 50 76 76 86 76 86 86 85 95 9885
0 43 43 52 77 89 89 86 93 を示します。 86
0 38 46 37 45 71 81 72 81 81 88 81
0 42 50 41 50 76 85 76 85 85 90 85
..簡潔にするためにカット

このセクションでは、プラットフォームでサポートされているアクティブなセッションの最大数であるセッションテーブルの使用率を示します。 80%を超える値は調査を保証します。

リソース使用率 (%)最後の60秒の間に:
セッション
:0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

次の 3 つのセクションでは、パケットバッファの使用率を示します。パケットバッファは、以前のパケットがコアまたはプロセスによって処理されている間にパケットが失われないようにするために使用されます。 80%を超える値は調査する必要があります。パケットバッファ: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 記述子: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0
0 0 0
0 0 0 0 0 0 0 0
0 0 0 0

0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0

0
0 0 0 0 0 0 0 0

パケット記述子(オンチップ): 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

出力をチェックインする事項:

最後の CPU 60 秒間の負荷を確認します。いずれかの数値が 100 に近い場合は、パフォーマンス CPU の問題の原因として高い値が考えられます。
「パケットバッファ」と「パケット記述子」のセクションを確認してください。 100 に近い数値がある場合、パケットバッファが不足している可能性があります。
セッションセクションを確認します。数値が 80 に近いか、または 80 を超える場合、パフォーマンスの問題はセッションに関連している可能性が高くなります。

いくつかのコマンドは、特定の測定値がリソースモニターのしきい値を超える理由を特定することができます。

セッション情報を表示します。

サポートされているセッション数、現在アクティブなセッション数に関連するすべてのデータを出力し、パケットレート、新しい接続確立率、スループットについて通知します。これらのパラメータのいずれかが非常に高い場合、データプレーンが上昇する可能性があります CPU 。

> セッション情報の表示

target-dp: *.dp0
--------------------------------------------------------------------------------
サポートされるセッション数: 262142
アクティブ < If this figure rises to the level of the supported sessions,
セッション数: 3 アクティブ TCP セッション数: 0プラットフォームが最大容量に達しています。
アクティブセッション数 UDP : 1
アクティブ ICMP セッション数: 0
BCAST アクティブセッション数: 0
アクティブセッション数: 0 MCAST
アクティブな予測セッション数: 0
セッションテーブルの使用率: 0%
起動後に作成されたセッション数: 332481
パケットレート: 28/s異常で突然の高いパケットレートが DoS 攻撃を示している可能性があります。
スループット: 13 kbps
新しい接続確立レート: 0 cps
--------------------------------------------------------------------------------
セッション
タイムアウトタイムアウト値がアグレッシブすぎるか緩和されすぎると、システムがリソースを使い果たします。
TCPデフォルトタイムアウト: 3600 秒
TCP セッションタイムアウト受信前 SYN-ACK : 3
TCP ウェイハンドシェイク前の 5 秒セッションタイムアウト: 10 秒
TCP ハーフクローズセッションタイムアウト: 120 秒
TCP セッションタイムアウト TIME_WAIT: 120 秒セッションタイムアウト:未確認の場合は 15 秒セッション
TCP RST タイムアウト: 30 秒
UDP のデフォルトタイムアウト: 30 秒
ICMP
その他の IP デフォルトタイムアウト: 30 秒
キャプティブポータルセッション:
:
TCP UDP 60秒、その他 IP のプロトコル: 60 秒
--------------------------------------------------------------------------------
セッションの加速エージング: True
加速エージングがオフになっている場合、セッションの一部は、必要以上に長くセッションテーブルでアクティブなまま
で、リソースを使用することがあります。
加速エージングしきい値: 使用率スケーリング係数の 80%
: 2 X
--------------------------------------------------------------------------------
セッション設定
これらのいずれかのトラブルシューティングがオフにされ、電源が入っていない場合、他の
方法で
破棄される不正なパケットを検査するために追加のリソースを消費できます。
TCP - 非 SYN ファーストパケットを拒否する:
Hardware 真の
IPv6ファイアウォール: 真
の厳密 TCP / IP チェックサム: 真の到達
ICMP 不能パケットレート: 200 pps
--------------------------------------------------------------------------------

アプリケーショントリクリングスキャンパラメータ: アプリケーションのトリリングを決定するためのタイムアウト: 10 秒
スキャンを開始するリソース使用率しきい値: 80% 通常の
エージングに対するスキャンのスケーリング: -------------------------------------------------------------------------------- 80% スキャンの動作を示す: 80%
リソースが上限に

firewall 達したときの動作を示します
。
--------------------------------------------------------------------------------
Pcap トークンバケットレート : 10485760
--------------------------------------------------------------------------------
セッションあたりのキューイングされた mcast パケットの最大保留 : 0
--------------------------------------------------------------------------------

デバッグデータプレーン・プール統計

システムで使用されているすべてのバッファのステータスと、そのステータスを返します。

左側の数値は、どのくらいのバッファーがまだ利用可能なを示します
右側の数値は、合計サイズを示します
場合 0 に左の滴の数、バッファーが使い果たされて

> デバッグデータプレーン・プール統計

Hardware プール
[ 0 ] パケットバッファ : 57223/57344 0x8000000030c00000 [
1] ワークキューエントリ : 229315/229376 0x8000000037c00000
[ 2] 出力バッファ : 1007/1024 0x800000000fc00000
[ 3] 結果 : DFA 3995/3995/4000 0x8000000039800000
[ 4 ] タイマーバッファ : 4096/4096 0x8000000039be8000
[ 5] PAN_FPA_LWM_POOL : 1024/1024 0x800000000fd00000
[ 6] コマンド : ZIP 1023/1024 0x800000000fd40000
[ 7] PAN_FPA_BLAST_PO : 1024/1024 0x800000000ff40000

ソフトウェアプール
[ 0] ソフトウェアパケットバッファ 0 ( 512): 32767/32768 0x8000000043b2a680
[ 1] ソフトウェアパケットバッファ 1 ( 1024): 32768/32768 0x8000000044b4a780
[ 2] ソフトウェアパケットバッファ 2 ( 2048): 81920/81920 0x8000000046b6a880
[ 3] ソフトウェアパケットバッファ 3 (33280): 2044 80/20480 0x8000000050bba980
[ 4] ソフトウェアパケットバッファ 4 (66048): 304/304
0x80000000795cea80 [ 5] 共有プール 24 ( 24): 560000/560000 0x800000007a8f6780
[ 6] 共有プール 32 ( 32): 530000/530000/530000/5300000 /5300000
0x800000007b7eaa80 [ 7] 共有プール 40 (40): 70000/70000 0x800000007ca1cf00
[ 8] 共有プール 192 ( 192): 1269999/1270000 0x800000007cd0cf80
[ 9] 共有プール 256 ( 256): 140000/140000 0x800000008ba70880
[10] ZIP 結果 ( 184): 1024/1024 0x80000000a1827300
[11] CTD AV ブロック (1024): 32/32 0x80000000be43d380
[12] Regex 結果 (11544): 8000/8000
0x80000000be466100 [13] SSH ハンドシェイク状態 (6512): 64/64 0x80000000c580c680
[14] SSH 状態 (3248): 512/512 0x80000000c5872480
[15] TCP ホスト接続 (176): 15/1 0x80000000c5a08e80 6

はいカウンターグローバルフィルターデルタを表示します。

コマンドが 2 回目以降に実行された後に、現在の反復と前の反復の間の時間枠でトリガーされたグローバルカウンタのスナップショットを返し、破棄されたパケットの異常な数を公開する可能性があります。

> カウンタグローバルフィルタデルタの表示はい

グローバルカウンタ:
最後のサンプリングからの経過時間: 2.981 秒

名前値レート重大度カテゴリの側面の説明
--------------------------------------------------------------------------------
pkt_recv 89 29 info パケット pktproc
パケット受信 pkt_recv_zero 87 29 info パケット pktproc パケットを受信 pkt_recv_zero QoS 0
pkt_sent 3 1 info パケット pktproc パケットを受信 session_allocated 1 0 情報セッションリソースセッション session_freed 割り当てられたセッションセッション session_installed 1 0 info セッション
リソースセッションが
解放された session_installed 1 0
情報セッションリソースセッション flow_arp_pkt_rcvインストール済み
83 27 情報フローパケット ARP flow_host_pkt_rcv 2 flow_host_pkt_rcv 0
情報フロー mgmt コントロールプレーンから受信した mgmt パケット
flow_host_pkt_xmt 2 0 情報フロー mgmt コントロールプレーンに送信されたコントロール flow_host_service_allow プレーンに送信された
2 0 情報フロー mgmt デバイス管理セッション
appid_ident_by_icmp icmp タイプ dfa_sw 2 0 info
dfa pktproc ソフトウェアaho_sw 1 0 info aho pktproc ソフトウェアを使用してdfa一致の合計数
ctd_用ソフトウェアの合計使用量 AHO
pkt_slowpath 2 0 info ctd pktproc パケットスローパス pkt_flow_npによって処理される
87 29 info パケットリソースパケットがモジュールフローステージ np に入pkt_flow_host
2 0 info パケットリソースパケット入力されたモジュールフローステージホスト
--------------------------------------------------------------------------------
合計カウンタ: 16
--------------------------------------------------------------------------------

いくつかの一般的なカウンタについて説明しました。

カウンター	説明
pkt_recv	受信したパケット
session_allocated	セッション割り当て
flow_ipfrag_recv	ipfrag 受信レート
dfa_sw	sw による dfa マッチング
dfa_fpga	fpga による dfa マッチング
ctd_pkt_slowpath	ctd スローパスによって処理される pkt
aho_sw	バイ sw
aho_fpga	バイ fpga
log_traffic_cnt	トラフィックログ数
flow_fwd_l3_ttl_zero	廃棄されたパケット: IP TTL
fpga_pkt	fpga 要求によって pkt を保持します。注: これは累積カウンタではありませんが、現在待機中のパケット数を表 FPGA します。

システムの統計情報のセッションを表示します。

すべてのデータプレーンの集約されたパケットレートとスループット値を、自動的に更新するライブダッシュボードで表示します。

システム統計: ('q' を終了するには、 'h' をヘルプに使用)

デバイスがアップしている: 0 日 2 時間 34 分 57 秒
パケットレート: 32/秒
スループット : 92 Kbps
合計アクティブセッション : 14
アクティブセッション : 8 アクティブセッション : 4 アクティブセッション : TCP
UDP
ICMP 2

'a' を押して戻って 's' を押して 'トップ 20 アプリケーション' を表示する切り替え

トップ 20 アプリケーション統計: ('q' 終了する場合は、ヘルプを 'h' )

仮想システム: vsys1
アプリケーションセッションのバイトのバイト
-------------------------------- ---------- ------------ ------------
ssl349 47051 53368023
Firefox-アップデート 4 32503 31679603
グーグルベース 57 19879 17687367
ms-- 更新プログラム 30 2513 2413399
tor 1 715 710161
ウェブブラウジング 60 1140 588357
ping2920 5840 572320
ウィンドウプッシュ通知57 8 19 266737
apt-get 6 662 260149
dns728 1484 185056
dhcp124 248 86800
ms-spynet 3 71 45382
ocsp 9 215 33311
グーグルアップデート 2 28 8624
ntp45 90 8100
ipv6 2 64 5248
sip 5 52283ldap
ldap 8 92241
不十分なデータ 5 13 780
icmp 6 520

また、トラフィックの種類や構成の複雑さが、使用率を増やす可能性があることに注意することも重要です CPU 。したがって、トラフィックパターンを調べて、高い使用率の原因となる可能性のあるアプリケーションを理解することが重要 CPU です。

管理プレーン

mp-monitor で「---top」を検索するか.logまたはからシステムリソースの表示コマンドを実行して、管理プレーンリソースの使用状況を確認 CLI します。このコマンドの出力例を次に示します。

>表示システムリソース

top - 03:40:57 アップ 20 分, 0 ユーザー, 負荷平均: 0.00, 0.01, 0.03

タスク:合計116、1ランニング、115睡眠、0停止、0ゾンビ

Cpu(s):1.6%us、1.3%sy、0.0%ni、96.2%id、0.5%wa、0.0%hi、0.4%si、0.0%st

Mem: 3635080k 合計、2327864k 使用済み、1307216k フリー、37772k バッファー

スワップ: 合計 2007992k、 0k 使用済み, 2007992k 無料, 1871932k キャッシュ

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1837 ルート 15 -5 18036 3508 2032 S 8 0.1 0:35.23 sysd

1 ルート 20 0 1768 560 488 S 0.0 0:00.75 init

2 ルート 20 0 0 0 0 S 0 0 0:00.00 kthreadd

3 ルート RT 0 0 0 0 0 0 0 S 0:00.00 移行/0

次に、管理プレーンでのリソースの使用状況が問題の原因になっている可能性があることを示します。

回線上の %wa CPU が高い場合、これは管理プレーンが io (スワップおよびディスクバウンド) で待機していることを示します。
スワップラインの空きメモリが高い。
CPU devsrvr、mgmtsvr、およびアプリ Web プロセスが高い場合。

トラフィックパターン分析

トラフィックパターンがパフォーマンスの問題の原因として疑われる場合は、外部のパケットキャプチャを顧客に要求します。トラフィックがオフロードされている場合は特にすべての firewall トラフィックを表示するわけではないため、キャプチャを実行することは推奨されません。

高いデータプレーンのトラブルシューティング方法 CPU

Symptom

Resolution

Other users also viewed: