SNMPプロセスが原因でCPU使用率が高い場合のトラブルシューティング
はじめに
このドキュメントでは、9800ワイヤレスLANコントローラ(WLC)のSNMPプロセスに対する高いCPU使用率をトラブルシューティングし、解決するための構造化されたアプローチについて説明します。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- ワイヤレスコントローラ：17.09.03を実行するC9800-80-K9
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
ログ収集
CPU使用率パターンの特定SNMPプロセスにリンクされているCPU使用率が高いというレポートを受け取った場合、最初の手順は、指定されたタイムフレームにわたって詳細なログを収集することです。これは、SNMPプロセスが最もアクティブでリソースを大量に消費する時間を特定するために不可欠な、CPU使用率のパターンまたは傾向を確立するのに役立ちます。
ログ収集を開始する前に、トラブルシューティングプロセスをサポートするために使用される特定の情報を収集することが不可欠です。まず、この問題に関する情報をいくつか収集します。
- システムでスパイクが発生していないか、使用率が一貫して高いか。
- どちらの場合も、使用率は何パーセントですか。
- CPU使用率が高い頻度は何ですか。
- 各SNMPサーバがWLCをポーリングする頻度はどのくらいですか。
- トップトーカーは誰ですか。
10分のスパンで2分間隔で9800 WLCからのコマンド出力を収集します。このデータを使用して、高いCPU使用率の問題、特にSNMPプロセスに関連する問題を分析できます。
#terminal length 0 #show clock #show process cpu sorted | exclude 0.0 #show process cpu history #show processes cpu platform sorted | exclude 0.0 #show snmp stats oid #show snmp stats hosts
ログ分析
これらのログを収集した後、影響を理解するために分析する必要があります。
CPU使用率ログの例を見て、最もCPUを消費しているSNMPプロセスを特定してみましょう。
WLC#show process cpu sorted | exclude 0.0 CPU utilization for five seconds: 96%/7%; one minute: 76%; five minutes: 61% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 250 621290375 58215467 10672 58.34% 39.84% 34.11% 0 SNMP LA Cache pr <-- High utilization 93 167960640 401289855 418 14.50% 11.88% 9.23% 0 IOSD ipc task 739 141604259 102242639 1384 8.57% 6.95% 7.21% 0 SNMP ENGINE 763 7752 34896 222 4.00% 3.41% 1.83% 5 SSH Process 648 6216707 181047548 34 0.72% 0.37% 0.31% 0 IP SNMP 376 3439332 51690423 66 0.40% 0.36% 0.25% 0 SNMP Timers 143 3855538 107654825 35 0.40% 0.35% 0.23% 0 IOSXE-RP Punt Se 108 6139618 17345934 353 0.40% 0.30% 0.34% 0 DBAL EVENTS
show process cpu sorted | exclude 0.0コマンドの出力は、SNMPプロセスが実際に不均衡な量のCPUリソースを消費していることを示しています。具体的には、SNMP LA Cache prプロセスが最もCPUに負荷がかかり、その後に他のSNMP関連プロセスが続きます。
次の一連のコマンドは、SNMPの使用率が高いプロセスを掘り下げる際に役立ちます。
WLC#show snmp stats oid time-stamp #of times requested OID 11:02:33 Austral Jun 8 2023 27698 bsnAPIfDBNoisePower <-- Frequently polled OID 11:02:23 Austral Jun 8 2023 1 sysUpTime 11:02:23 Austral Jun 8 2023 17 cLSiD11SpectrumIntelligenceEnable 11:02:23 Austral Jun 8 2023 1 cLSiD11SpectrumIntelligenceEnable 11:02:23 Austral Jun 8 2023 6 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:19 Austral Jun 8 2023 24 clcCdpApCacheApName 11:02:19 Austral Jun 8 2023 1 clcCdpApCacheDeviceIndex 11:02:19 Austral Jun 8 2023 9 cLApCpuAverageUsage 11:02:19 Austral Jun 8 2023 1315 cLApCpuCurrentUsage 11:02:19 Austral Jun 8 2023 2550 bsnAPIfDBNoisePower
show snmp stats oidコマンドの出力は、さまざまなOIDがポーリングされている頻度を明らかにします。bsnAPIfDBNoisePowerという特定のOIDは、要求数が非常に多いため、際立っています。これは、このOIDの積極的なポーリングが、WLCで見られる高いCPU使用率の一因である可能性があることを示唆しています。
OIDのbsnAPIfDBNoisePowerの動作と、そのデータの格納時間を理解してみましょう。
SNMPオブジェクトナビゲータに移動し、OIDの「bsnAPIfDBNoisePower」を検索します。
OIDの検索結果これで、bsnAPIfDBNoisePowerオブジェクトが、各APによって報告された各チャネルのノイズ出力を報告することについて理解できました。WLCによって管理されるチャネルとAPの数が多いことを考えると、このOIDによって生成されるSNMPデータは大量になる可能性があります。WLCが多数のAPにサービスを提供する場合、このOIDのポーリングによって生成されるデータの量は膨大になる可能性があります。これは、WLCがこれらの大量のSNMP要求を処理するため、高いCPU使用率につながる可能性があります。
同様に、積極的にポーリングされる特定のOIDの動作を理解する必要があります。
次のコマンドは、WLCをポーリングしているSNMPサーバを確認するのに役立ちます。
WLC#show snmp stats hosts Request Count Last Timestamp Address 77888844 00:00:00 ago 10.10.10.120 330242 00:00:08 ago 10.10.10.150 27930314 00:00:09 ago 10.10.10.130 839999 00:00:36 ago 10.10.10.170 6754377 19:45:34 ago 10.10.10.157 722 22:00:20 ago 10.10.10.11
このコマンドは、SNMPサーバのリストと、その要求カウントおよびポーリングアクティビティの最後のタイムスタンプを表示します。
9800 WLCをポーリングしている複数の異なるサーバがあることがわかります。過去10分間に収集された完全なログデータを確認すると、ポーリング頻度も測定できます。
これで、各サーバに移動して、問題のOIDがポーリングされる頻度を確認できます。この例では、OIDが30秒ごとにポーリングされており、必要以上に頻繁にポーリングされています。WLCは180秒ごとにRF/RRMデータを受信するため、OIDを30秒ごとにポーリングすると不要な処理が発生し、CPU使用率が高くなります。
問題のOIDとサーバが特定されたら、複数の異なるソリューションを試してWLCの負荷を軽減できます。
- SNMPサーバでのポーリング頻度を減らす。
- 操作の使用にOIDが必要ない場合は、SNMPサーバからのOIDのポーリングを無効にします。
- SNMPサーバを制御できない場合は、SNMPビューを使用して問題のOIDをブロックできます。
SNMPビューの設定
ブロックするOIDを除外する新しいビューを定義します。たとえば、OID 1.3.6.1 .4.1.14179.2.2.15.1.21をブロックして新しいビューを作成し、そのビューにOIDをアタッチするとします。
snmp-server view blockOIDView 1.3.6.1.4.1.14179.2.2.15.1.21 excluded <-- This is the OID of bsnAPIfDBNoisePower
snmp-server community TAC view blockOIDView RO <-- This command assigns the blockOIDView to the community myCommunity with read-only (RO) access.
snmp-server group TAC v3 priv read blockOIDView <-- This command assigns the blockOIDView to the group myGroup with the priv security level for SNMPv3.トラブルシューティングのヒント
- CPU使用率のベースライン：SNMPプロセスによって高い使用率が生じていない場合の、通常のCPU使用率レベルを文書化します。
- SNMP設定：コミュニティストリング、バージョン（v2cまたはv3）、アクセスリストなど、現在のSNMP設定を確認します。
- SNMPのベストプラクティス：9800 WLCのベストプラクティスドキュメントを使用し、SNMPの推奨設定をできる限り近くに一致させてください。
C9800(config)#snmp-server subagent cache
C9800(config)#snmp-server subagent cache timeout ?
<1-100> cache timeout interval (default 60 seconds)
- SNMPポーリングの頻度：頻度を高くするとCPU負荷の増加につながるため、SNMPクエリによってWLCがポーリングされる頻度を決定します。
- ネットワークトポロジとSNMPマネージャ：ネットワーク設定を理解し、WLCと対話しているすべてのSNMPマネージャを特定します。
- System Uptime:最後のリブートからの経過時間をチェックして、稼働時間とCPU使用率に相関関係があるかどうかを確認します。
- 最近の変更：WLCの設定またはネットワークに対する最近の変更で、CPU使用率が高くなる時期と一致する可能性のあるものに注目してください。
- 9800 WLCでは、テレメトリに重点が置かれています。テレメトリは「プッシュ」モデルで動作します。このモデルでは、WLCはクエリを実行することなく、関連する情報をサーバに送信します。SNMPクエリがWLCのCPUサイクルを消費し、操作の問題を引き起こしている場合は、テレメトリに移行することをお勧めします。
結論
CPU使用率データを系統的に分析し、それをSNMPポーリングアクティビティと関連付けることで、Cisco 9800 WLC上のSNMPプロセスによって発生するCPU高使用率の問題をトラブルシューティングし、解決できます。実装後のモニタリングは、トラブルシューティング作業の成功を確認し、最適なネットワークパフォーマンスを維持するために不可欠です。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
29-Jul-2024
|
初版 |
フィードバック