ディスカバリー MID サーバーの CPU 使用率が 100% - 良いか悪いか、なぜですか?Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } おそらくこれを読んでいるのは、イベント監視で、MID サーバーコンピューターが非常に高い CPU または 100% の CPU で長時間実行されているというフラグが立てられたためです。この記事は、これについて高いレベルで議論することを目的としており、特定のメーカー/モデルに対して実行される個々のプローブ/パターンについては、通常、他のナレッジ記事で個別に扱われ、問題チケットがリンクされている可能性があるため、意図的に詳細には触れません。 100%CPUは良好です100% CPU が不良ディスカバリーはなぜこれほど多くの CPU を使用し、なぜ増加傾向にあるのでしょうか? Windows ディスカバリーでの変更マルチスレッド Shazzamプローブからパターンへの移行、および MID サーバーへの処理の一般的なオフロード通常の新しいパターンJavaのメモリガベージコレクションMID サーバーホストで実行されているウィルス対策 100%CPUは良好です 水平ディスカバリーは、IP 範囲全体をスキャンし、CMDB に記録できるすべてのものを記録することを目的としているため、運用担当者はその最新情報を使用して効果的に仕事をすることができます。MID サーバーがディスカバリーの実行中に CPU 時間を使用する場合、ターゲットハードウェアから情報をフェッチし、インスタンスに送り返す前に前処理を行うプローブが実行されています。使用できる CPU 時間が長ければ長いほど、より多くのことができます。MID サーバーアプリケーションとそれが実行するディスカバリープローブはマルチスレッドであり、Java JVM、コンピューターオペレーティングシステム、および仮想ハイパーバイザーによって CPU コアとタイムスライスが指定されている場合は、それらが使用されます。より多くの IP を、より頻繁にスキャンできるため、ディスカバリー機能からより多くの価値を得ることができます。 CPU が 100% でもコンピューターが壊れることはありませんが、ディスカバリーの実行中にオペレーティングシステムで利用可能な処理リソースが最大限に使用されていることを意味します。オペレーティングシステムは100%CPUで動作するように設計されており、CPUをより高い優先度で必要とするプロセスが確実にCPUを取得できるように設計されており、その下のハードウェアもCPUを温度制限内に収めるように調整します。ストレージやメモリが不足すると問題が発生しますが、100% の CPU で実行すると、ジョブが処理される速度が決まるだけです。資産を十分に活用することは費用対効果が高いです。 100% CPU が期待され、上記の理由から望まれます。これは水平ディスカバリーの意図的な設計です。Quebec リリーステストでは、MID サーバーが 10,000 台のデバイスディスカバリースケジュールの開始時に一貫して 100% CPU を使用することが実証されました。その後、スケジュールが少し変動し、スケジュールが終了するとアイドル状態に戻ります。ターゲットが何かをしている可能性があるときに、ほとんどのスレッドをブロックしてターゲットからの応答を待つと、検出が遅くなるため、スレッドが増えて、ほとんどのスレッドがいつでも実際に何かを処理するようになります。このテストでは、使用可能な CPU を 4 から 8 に倍増しても、スケジュールを通じて使用される平均 CPU とほとんど違いはありませんでしたが、スケジュールはより短い時間枠で完了することができました。 OS によって報告された 100% CPU は、それが VM である場合、嘘である可能性さえあります。物理CPU使用率は唯一の真の指標であり、OSレベルではなくハイパーバイザー監視ツールから取得する必要があるかもしれません。 100% CPU が不良 監視ツールからのアラートが問題になる可能性があります。アプリケーションサーバーにアイドル期間があり、ディスカバリーの実行中に見られる程度に CPU が急増することはめったにありません。検出されるデバイス、ネットワークトラフィック、および ServiceNow インスタンス自体への影響を最小限に抑えるために、ディスカバリースケジュールを時間外で実行することが推奨される傾向がありました。その結果、平日の夜は8〜10時間かけてすべての重要な機器をスキャンし、週末は重要度の低い機器に追いつくために長い時間を費やすことになります。結果として得られる矩形波グラフは、ディスカバリーが実行されていないときはCPUがほとんどなく、実行されているときはほぼ100%のCPUになり、監視ツールを心配させます。 専用ホスト、または専用リソースを備えた VM では、100% CPU は他のコンピューターに影響せず、これは常に推奨されることであるため、これらは誤ったアラートです。この場合、監視ツールでこれらの特定のホストの CPU アラートのしきい値、アラートルール、および時間枠を調整することが正しい解決策です。 ただし、仮想化とクラウドテクノロジーの変化により、専用ハードウェアが使用できなくなる可能性が高くなり、MID サーバーホストが同じクラウドまたは ESX ハードウェアで実行されている他のホストに影響を与え、実際のハードウェアリソースと CPU 時間が他の VM やアプリケーションと共有される可能性があります。 ほとんどのVMware ESX Serverはオーバーコミットされており、各VMで必要なときにCPUリソースとメモリリソースが動的に割り当てられます。これは、CPU使用率のわずかな変動が複数のVM間で均等になり、より少ない物理リソースで済むという考えに基づいており、仮想およびクラウドテクノロジーの重要なセールスポイントです。MID サーバーのリソース使用率のパターンは、ほとんどアイドル状態だった後、大きな CPU 需要があり、その後、その日の残りの時間はアイドル状態に戻るということです。つまり、それらのリソースを使用していた他の VM は、突然、リソースが奪われてしまうことを意味します。ディスカバリー負荷分散クラスター内に複数の MID サーバーホストがあると、それらがその時点で同じハードウェア上にある場合、その影響が大きくなる可能性があります。 OS全体を管理すると同時に、リソースを必要とするアプリケーションにリソースを割り当てることがオペレーティングシステムの主な機能であり、物理リソースに対する需要を管理するのは仮想ハイパーバイザーの仕事です。この場合、通常は CPU 用にハイパーバイザー VM 設定を調整するのが正しい解決策です。 ディスカバリーはなぜこれほど多くの CPU を使用し、なぜ増加傾向にあるのでしょうか? 水平ディスカバリーの主な目的は、最短時間でできるだけ多くのものを検出し、利用可能なすべてのCPUを使用してそれを行うことであり、製品の開発は、リリースごとにより多くのことをより迅速に行うために変更を加え続けています。一般的に MID サーバーホストの最小ハードウェア推奨事項は長年改訂されていませんが、ディスカバリーではより多くのハードウェアが使用されるようになりました。新しいメジャーバージョンごとに、「MID サーバー、ディスカバリー、クラウド管理、およびサービスマッピングのリリースノート」にこれらの変更の概要が記載されています。これにより、多くの場合、CPU 使用率が高くなります。 Windows ディスカバリーでの変更 マドリード/ニューヨーク中部の WMI の代わりに Powershell/WinRM が使用され、Paris 以降にターゲットの Windows Server で利用可能な最新の管理テクノロジーが自動的に選択されます。各 Windows プローブまたはパターンは PowerShell にシェルアウトするので、Windows 関連の MID サーバースレッドごとに powershell.exe セッションも実行されます。これらは、特にネイティブ WMI 要求を実行しているプローブと比較した場合、CPU (およびメモリ) の使用率に大きく影響します。この変更は、長年にわたる Microsoft の管理技術の変更により、最新の Windows バージョンの Discovery を引き続きサポートするために必要でした。 マルチスレッド Shazzam ポートスキャナープローブは、MID サーバーごとに一度に 1 回実行されますが、プローブ内でマルチスレッド化されるようになりました。デフォルトでは、Orlando 以降のスレッドが 1 個から 5 個になり、各スレッド内で 100 個のスキャナーが実行されます。IPをスキャンできる速度を上げるために、他の最適化が追加されました。このようにして、単一のディスカバリースケジュールで数百万の IP をわずか数時間でスキャンできます。 プローブからパターンへの移行、および MID サーバーへの処理の一般的なオフロード パターンはロンドンで導入され、ニューヨーク以降、古い顧客が移行できるようになりました。これらには、ターゲットを探索し、データを処理して CMDB、関連 CI、接続、および関係の属性を抽出するための、場合によっては数百のステップが含まれます。パターンは、MID サーバーでほぼすべてのロジックとデータ処理を実行します。これにより、次に何をすべきかを決定するたびにインスタンスを前後に移動することによる遅延が軽減されます。同等のプローブのセンサーは、ターゲット上でほんの一握りのコマンドのみを実行し、インスタンス内のすべての処理を実行するために使用されていました。クラウドディスカバリーや大規模なネットワークデバイスの場合、これは膨大な量のデータと処理量です。その中でデータを使用するためにこれらの大きなペイロードを解析すると、それぞれ何分にもわたって大量の CPU が使用される可能性があります。大きなパターンを含むほとんどのパターンでは、インスタンスであとに行う必要があるのは、CI を挿入または更新するための CMDB 識別および調整処理だけです。また、一部のプローブでは、MID サーバーで実行される後処理スクリプトに処理が移動されています。 通常の新しいパターン メジャーアップグレードの合間に「ディスカバリーとサービスマッピングパターン」ストアアプリによって提供される毎月の帯域外リリースでは、新しいクラウド環境、新しいハードウェア、および新しいアプリケーションを検出するための新しい機能が追加されます。多くの場合、これにより、より多くの IP が既にスキャンされ、探索され、より深く探索されたり、既存の検出されたサーバー上のアプリケーション (クラウドサービスやそれらが実行されている仮想化リソースなど) が探索されたりします。 Javaのメモリガベージコレクション ガベージコレクション 実行されるパターンが大きくなるほど、重要性が増す可能性があります。Java 8 を Java 11 にアップグレードした Quebec のアップグレード後、および PRB1462926 の修正が実装される前に、MID サーバーは、スレッドが終了した後にメモリヒープをクリアするために多くの CPU を費やしていました。これは、Java 11 のデフォルトのガベージファーストガベージコレクター (G1GC) が、MID サーバーなどの小規模な JVM のパラレルコレクターほど効率的ではなかったためです。これをparallelGCに戻す修正バージョンに直接アップグレードするため、多くの顧客はこれを見ることはないでしょうが、これはJavaが独自のメモリ管理を行い、JavaプロセスのCPU使用率に含まれ、オペレーティングシステムのCPU使用率に隠されていないことを強調しています。 MID サーバーホストで実行されているウィルス対策 MID サーバーがプローブ (特に PowerShell ベースのプローブ) を実行する場合、ディスクに書き込まれる一時スクリプトが使用されます。一時スクリプトは、多くの場合、その特定のプローブに固有の臨機応変に生成され、プローブごとに専用のpowershell.exeプロセスによって実行されます。ウイルス対策ソフトウェアは、すべてのスクリプトファイルと実行をチェックするため、MID サーバーの Java プロセスと Powershell の子プロセスによってすでに使用されている CPU にかなり追加されることがわかっています。カスタマーのさまざまなウイルス対策/セキュリティスキャンに必要な追加の CPU は、CPU を MID サーバーホスト専用にする場合、またはスキャナーに除外を追加できるかどうかを考慮する必要があります。たとえば、MID サーバーの CPU を完全に使用しているディスカバリースケジュール中に、Microsoft Defender for Endpoint (ATP) は MID サーバーと Powershell プロセスを合わせたのと同じ量の CPU を使用することが確認されています。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } Instructions<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } これについて何ができるでしょうか?これについて何か手を打つべきでしょうか?以下が判断するのに役立ちます。 アラートの防止物理 CPU のオーバーコミットの回避 (vCPU > pCPU)ホストの CPU リソースを変更する MID サーバーの CPU リソースを増やすMID サーバーの CPU リソースを削減する 曲線を平坦化する検出を減らすサービスマッピングを使用したサービス中心のディスカバリー1 日/週全体のディスカバリーの再スケジュールMID サーバーあたりのホスト数を考慮MID サーバーアプリケーションのスロットル ワーカースレッドMID Server リソース予約ディスカバリープローブの抑制 アラートの防止 正しく推奨される処理は、MID サーバーの実行を設定した時間に MID サーバーを実行し、それ以外のときにアイドル状態になるときには MID サーバーの動作を予測し、[ディスカバリースケジュール] 期間中には CPU 使用率の高いイベントのアラートを作成しないように監視ツールを設定することです。 残念ながら、MID サーバーホストの CPU グラフのパターンは、現在使用されている種類の自動監視ツールに対して根本的に「悪い」ように見えます。残りの時間がアイドル状態のときに、1 時間から 2 時間にわたって >90% の CPU 使用率が発生するのは、これらのツールが気をつけるべき典型的なことです。アプリケーションサーバーとしては問題を示している可能性がありますが、これはまさにディスカバリーの目的です。 Paris リリース以降、イベント管理セルフヘルスモニタリング機能は MID サーバーの問題レコードに基づいてアラートを作成します。有効にすると、MID サーバーが 30 分間にわたって平均 >95% の CPU にとどまると、これらの問題レコードがデフォルトで作成されます。デフォルト/推奨の MID サーバー CPU アラート/MID サーバーの問題のしきい値は、ディスカバリーを行う MID サーバーにとって現実的ではありませんMID サーバーリソースしきい値アラートこれは、あちこちで奇妙な統合を行う一般的な MID サーバーでは問題ありません。多くの場合、ユーザーの更新によってランダムにトリガーされる小さなジョブですが、何千もの IP の水平ディスカバリースケジュールには適していません。 物理 CPU のオーバーコミットの回避 (vCPU > pCPU) VMware コミュニティやブログの投稿を検索したり読んだりすると、ベスト プラクティスの推奨事項は、一般的に保守的であり、物理 CPU コアを過剰にコミットしないことです。 CPU コアが MID サーバーホスト専用である場合、その CPU 使用率が ESX サーバー上で実行されている他の VM に影響を与えることはありません。 ホストの CPU リソースを変更する MID サーバーの CPU リソースを増やす 100% で稼働している MID サーバーは、指定するとより多くの使用量が発生することを意味します。一般的に、ピークを持つ可能性は低く、それらのピークにとどまる時間が短くなります。上記のケベック州のテストで述べたように、CPUを推奨の最小コアである4コアから8コアに倍増しても、CPUグラフの形状は基本的に同じで、スケジュールを通じて使用される平均CPUとほとんど変わらず、唯一の効果はそれをより短い時間に圧縮することでした。 短時間でより多くのデータを検出するには、MID サーバーの負荷分散クラスターと併用することをお勧めします。 ただし、オーバーコミットされた仮想環境では、これは、以前よりも多くのリソースを他のVMから奪うことを意味し、それらのCPUパフォーマンスに比較的大きな影響を与えます。 MID サーバーの CPU リソースを削減する はい、これは直感に反しますが、我慢してください。CPU の数を減らすか、VM に指定できる CPU の割合に上限を設定することができます。これは、MID サーバーを調整し、CPU 使用率グラフをフラット化する方法でもあります。オペレーティングシステムの観点からは、ハイパーバイザーに騙されて 100% CPU であると思い込んでいるため、100% CPU のままですが、実際には物理 CPU リソースのほんの一部しか使用していません。ほとんどのディスカバリー MID サーバーは、ESX サーバー上の Windows VM にインストールされる傾向があるため、OS と MID サーバーを再インストールしなくても、割り当てられた CPU と動的割り当てルールを変更できます。 これは、必要なすべてのジョブとディスカバリースケジュールを必要な時間枠内で実行できる場合、通常は必要ありません。 最小の推奨事項として、MID サーバーのインストールごとに 4 コア 2GHz CPU を文書化しています。この仕様では、MID サーバーは最初からディスカバリースケジュールのかなりの部分で 100% CPU で実行されます。ハードウェアを共有している他の VM への影響が大きすぎる場合は、影響を小さくします。 曲線を平坦化する 週全体の CPU 使用率グラフが平坦で、CPU 使用率がより安定し、ピークとトラフが少なく、必要に応じて十分な VM とハードウェアを購入することが、コストとプロビジョニングの観点から理想的です。ServiceNow 製品を使用する IT 運用担当者の要件を満たしながら、それを実現できる場合は問題ありません。これには基本的に3つの方法があります。 インスタンス内でスロットルインし、ジョブを減らして残りのスケジュール済みジョブを時間の経過とともに分散させることで、ピーク時ではなく、継続的なデマンドが得られるようにします。ハードウェアを使用して MID サーバーを調整し、使用可能な CPU 時間を制限します。上記を参照してください。MID サーバーまたはディスカバリーソフトウェア設定を使用して、MID サーバーを調整します。 以下は、そのためのいくつかの方法です。 検出を減らす 水平ディスカバリーの欠点は、可能な限りすべてを細部まで発見したいという誘惑に駆られることです。それは可能ですが、実際にそれが必要ですか?誰がデータを使用し、どのようなデータが必要か?そのデータはどの程度最新である必要がありますか? たとえば、サーバーのネットワークアダプターとスイッチポート間のネットワーク接続の L2 マッピングデータを使用している人はいますか。アプリケーションレベルでのサーバー間のTCPレベル接続のL3データは、ニーズに十分対応していますか?これには大量のデータが含まれており、MID サーバーで実行されているディスカバリープローブを使用してサーバー、ルーター、およびスイッチから抽出する必要があります。また、プロパティでオフにすることができます。 サービスマッピングを使用したサービス中心のディスカバリー 特定のサービスは、関連するロードバランサー、アプリケーション、サーバー、データベース、およびストレージを表す 10〜50 のメイン CI のみで構成される場合があります。アラートまたは機能停止からのインシデントが報告された場合、それだけで整理できます。発見されるものがはるかに少ないため、毎晩や毎週ではなく、数時間ごとに再発見することができます。重要なサービスに直接関係しない他のすべてのものは、検出される頻度を大幅に減らすことができ、MID サーバーの負荷を大幅に軽減できます。 1 日/週全体のディスカバリーの再スケジュール 「毎晩1回の大きなスケジュール」のやり方から脱却してみてください。スケジュールを分割した場合は、「後で実行」機能を使用してスケジュールを直接実行しているか、意図的にスケジュールを設定している可能性があります。ほとんどの ServiceNow の顧客はグローバルです。市場がローカルであっても世界中に従業員とハードウェアがあるため、ダウンタイムは発生しません。 スケジュールをデータセンターまたは地域に分割し、それらのスケジュールの開始時間を週全体でずらします。ただし、これらの小さなスケジュールを実行しても 100% の CPU を期待できますが、グラフは 1 つの大きな正方形ではなく、のこぎりの歯のようになります。 MID サーバーあたりのホスト数を考慮 同じホストに複数の MID サーバー (おそらく本番用と準本番インスタンス用に 1 台) をインストールすると、MID サーバーが相互に影響を与える可能性があります。MID サーバーが MID サーバーダッシュボードで CPU 使用率が高いと報告している場合、数値はホスト全体の測定値であり、CPU を使用しているのは MID サーバーではないかもしれません。ホストが他のアプリケーションにも使用されていた場合は MID サーバーではない可能性があります。MID サーバー専用のホストは共有ホストよりも優れており、1 つの MID サーバーに対して 1 つのホストの方が優れています。 MID サーバーアプリケーションのスロットル MID サーバーとディスカバリーのスループットを意図的に抑制し、処理できるプローブのスループットとレートを減らすことで平均 CPU 需要を減らすことは可能ですが、100% の使用率がすべてなくなるわけではありません。意図的にボトルネックとブロックを導入し、ジョブはスレッドまたは接続プールを待機します。 ただし、これらの操作はお勧めしません。MID サーバーは、迅速な応答や高いジョブ率を必要とする機能の ECC キューで発生する可能性のある問題のあるバックログを回避するために、可能な限り高速に実行されるように設計されているためです。実行時間が長いジョブがいくつかあると、非ディスカバリー統合を含め、キューに格納されている他のすべてのジョブが長時間実行できなくなるため、MID サーバーの制限が厳しくなるほど、この状況が発生する可能性が高くなります。 これを行うと、ディスカバリースケジュール時間が長引いて、CMDB で必要なすべてのデバイスをスキャンしたり、必要に応じて定期的に更新したりできなくなる可能性があります。 ワーカースレッド プローブを実行するために MID サーバーで利用可能なスレッドの数は、これらの MID サーバーパラメーターを使用して MID サーバーレベルで設定できます。プローブは、それぞれ特定のターゲット IP に対する IP ブロックの Shazzam ポートプローブ、Windows 分類プローブ、またはネットワークスイッチパターンです。 スレッドグループ値 (デフォルト)パラメーターメモ標準25threads.maxこれは 5 まで減らすことができます迅速20threads.expedited.maxこれは 5 まで減らすことができますインテラクティブ10 threads.interactive.maxこれに触れないでください。 インタラクティブプロパティには触れないでください。これは通常、MID サーバー自体のシステムコマンド (MID サーバーがまだ稼働中であることを示すハートビートプローブなど) でのみ使用されるため、制限されるべきではありません。 MID サーバーワーカースレッドプールの詳細については、「 KB0743566 MID サーバー最大スレッド数、ワーカーグループ、優先度およびキュー」を参照してください。 MID Server リソース予約 この機能は Paris で追加され、次のようなさまざまなことを行うために使用できます。 MID サーバーによって同時に実行される「大きな」プローブの数を制限するスロットルディスカバリー (インスタンスへの影響を最小限に抑えるため) 詳細については、ドキュメントの「 MID サーバーリソース予約 を参照してください。 ディスカバリープローブの抑制 Shazzam MID サーバーは一度に 1 つの Shazzam ポートスキャンプローブしか実行しませんが、Orlando バージョン以降、これは複数のスレッドを並列に実行し、それぞれが複数のスキャナーを同時に実行するように拡張されているため、当然 CPU 使用率が増加し、可能であれば 100% を超える CPU を何倍も使用します。 スレッド数とスレッドあたりのスキャナー数を減らすことができます。ドキュメントの mid.shazzam.threads および mid.shazzam.max_scanners_per_thread パラメーターを参照してください。 セッションプール SSH および PowerShell プローブは、セッションプールを介してターゲットに接続します。 Windows Powershell の場合は、「 」の mid.powershell_api.session_pool.max_size および mid.powershell_api.session_pool.target.max_size を参照してください。PowerShell の MID サーバーパラメーター または Windows ディスカバリーパラメーター ドキュメント) を参照してください。 SSH の場合は、「」の「mid.ssh.pool_thread_ratio」、および の「SSH ディスカバリーパラメーター」の「mid.ssh_connections_per_host」を参照してください。 これにより、セッションプールを待機している間にプローブがタイムアウトし、スレッドがブロックされる可能性があります。代わりに MID サーバーリソース予約を使用すると、キューのブロックを回避できます。