SNMPプロセスが原因でCPU使用率が高い場合のトラブルシューティング
はじめに
このドキュメントでは、9800ワイヤレスLANコントローラ(WLC)のSNMPプロセスに対する高いCPU使用率をトラブルシューティングし、解決するための構造化されたアプローチについて説明します。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- ワイヤレスコントローラ：17.09.03を実行するC9800-80-K9
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
ログ収集
CPU使用率のパターンの特定SNMPプロセスにリンクされているCPU使用率が高いというレポートを受信した場合、最初のアクションは、指定されたタイムフレームに渡って詳細なログを収集することです。これは、CPU使用率のパターンや傾向を確立するのに役立ちます。これは、SNMPプロセスが最もアクティブでリソースを大量に消費する時間を特定するために不可欠です。
ログ収集を開始する前に、トラブルシューティングプロセスをサポートするために使用される特定の情報を収集することが不可欠です。まず、問題に関する情報をいくつか収集します。
- システムでスパイクが発生しているか、使用率が一貫して高いか。
- どちらの場合も、使用率は何パーセントですか。
- CPU使用率が高い頻度は何ですか。
- 各SNMPサーバがWLCをポーリングする頻度はどのくらいですか。
- トップトーカーは誰ですか。
10分のスパンで2分間隔で9800 WLCからのコマンド出力を収集します。このデータは、特にSNMPプロセスに関連するCPU高使用率の問題の分析に使用できます。
#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はRF/RRMデータを180秒ごとに受信するため、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マネージャを特定します。
- システムアップタイム：最後のリブートからの経過時間をチェックして、アップタイムとCPU使用率に相関関係があるかどうかを確認します。
- 最近の変更：WLCの設定またはネットワークに対する最近の変更で、CPU使用率が高くなる時期と一致する可能性のあるものに注意してください。
- 9800 WLCでは、テレメトリに重点が置かれています。テレメトリは「プッシュ」モデルで動作します。このモデルでは、WLCはクエリーを実行することなく関連情報をサーバに送信します。SNMPクエリがWLCのCPUサイクルを消費し、操作の問題を引き起こしている場合は、テレメトリに移行することをお勧めします。
結論
CPU使用率データを系統的に分析し、それをSNMPポーリングアクティビティと関連付けることで、Cisco 9800 WLC上のSNMPプロセスが原因で発生するCPU高使用率の問題をトラブルシューティングして解決できます。実装後のモニタリングは、トラブルシューティング作業の成功を確認し、最適なネットワークパフォーマンスを維持するために不可欠です。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
29-Jul-2024 |
初版 |
フィードバック