パフォーマンスの争いまたはCPU時間をかかった人
それはすべてタンブラーから始まりました。 それが何であり、なぜそれが必要であったかについては、 http ： //habrahabr.ru/company/oktell/blog/108726/で説明されています。 つまり、4つの稼働中のコールセンターサーバーが等しく構成され、外部回線と内部回線、ユーザー、および内部データベースの設定がほぼ同じでした。 通信事業者は各サーバーで均一なリング負荷を受け取りましたが、サーバーはこれに対して異なる反応を示しました！
Nサーバーの構成とオペレーティングシステム
1 T1300 @ 1.66 1 GB RAM、Windows 2003 Standard Ed。 R2 SP1 32ビット
2 Intel Core Duo E8400 @ 3000 4 GB RAM、Windows 2003 Standard Ed.SP1 32ビット
3 Intel Pentium 4 3GHz 2 GB RAM、Windows 2003 Standard Ed。 SP2 32ビット
4 E3400 @ 2.60 2 GB RAM、Windows 2003 Standard Ed。 R2 SP2 32ビット
コミュニケーションの質に関する苦情に直面。 さらに、彼らはすべての電話について不平を言ったのではなく、「一部」について不平を言いました。 彼らは、VoIPテレフォニーの非常に特徴的な「クワキ」について不満を述べました。 「kwaks」が表示される理由は、負荷の増加に伴うコールセンターサーバーの1つ（最初）でのプロセッサの使用率の予測できない増加であることがすぐにわかりました。 これは、他のサーバーがそのような負荷にまったく気付かず、同じコール数でCPU負荷が増加しなかったという事実にもかかわらずです。 最初のサーバーが他のすべてのサーバーよりも著しく脆弱であるという事実にもかかわらず、そのような状況-プロセッサ使用率が100％に増加すること-は観察されるべきではありませんでした。
「ヘッドライトを拭く」、「車輪を蹴る」などの標準的な方法を採用したと言っても価値はないでしょう。最後に、コールセンターの設定もDBMSもサーバーの動作に影響を与えないという結論に達しました。 問題の本質を理解するための出発点は、プロセスリストのタスクマネージャーでは、どのプロセスもプロセッサー時間を消費しなかったという事実でしたが、パフォーマンスをモニターしている間、プロセッサー負荷履歴は20％の連続したカーネルプロセッサー負荷を示しました。
目標は、他のすべてのサービスに負荷がかかっていないときに、忙しいコアとは何かという質問に対する答えを得ることでした。 Microsoftの標準ユーティリティであるProcess Explorerは、リソースの主な消費者は「ハードウェア割り込み」であることを提案しました。 このような消費の理由をさらに分析するために、別の標準的なMicrosoftユーティリティであるKernrate Viewがダウンロードされました。 使用に関する推奨事項で説明されているように、コマンドラインは「C：\ Program Files \ KrView \ Kernrates \ Kernrate_i386_XP.exe >> log.txt」を実行し、しばらくしてCtrl-Cを押して停止しました。 次の形式の情報を含むlog.txtファイルを取得しました。
/ ================================
\ =============================== /
日付：2010/12/08時間：1:09:14
マシン名：RESERVCC
プロセッサー数：1
PROCESSOR_ARCHITECTURE：x86
PROCESSOR_LEVEL：6
PROCESSOR_REVISION：0e08
物理メモリ：1015 MB
ページファイル合計：2450 MB
仮想合計：2047 MB
PageFile1：\ ?? \ C：\ pagefile.sys、1524MB
OSバージョン：5.2 Build 3790 Service-Pack：1.0
WinDir：C：\ WINDOWS
Kernrateユーザー指定のコマンドライン：
Kernrate_i386_XP.exe
カーネルプロファイル（PID = 0）：ソース=時間、
25000イベント/ヒットのKernrateデフォルトレートを使用する
------------全体的な要約：--------------
P0 K 0：00：36.671（28.5％）U 0：00：09.671（7.5％）I 0：01：22.343（64.0％）DPC 0：00：29.484（22.9％）割り込み0：00：00.281（0.2％ ）
割り込み= 136809、割り込みレート= 1063 /秒
合計プロファイル時間= 128687ミリ秒
BytesStart BytesStop BytesDiff。
利用可能な物理メモリ、443772928、407339008、-36433920
利用可能なページファイル、2104172544、2093707264、-10465280
利用可能な仮想、2132660224、2131611648、-1048576
利用可能な拡張仮想、0、0、0
合計平均 レート
コンテキストスイッチ、609407、4736 /秒
システムコール、5078088、39661 /秒
ページフォルト、119817、931 /秒
I / O読み取り操作、11671、91 /秒
I / O書き込み操作、209479、1628 /秒
I / Oその他の操作、229216、1781 /秒
I / O読み取りバイト、39981700、3426 / I / O
I / O書き込みバイト、19240135、92 / I / O
I / Oその他のバイト、7130204725、31107 / I / O
-カーネルモードの結果：
-OutputResults：KernelModuleCount = 99
次の表の割合は、カーネルの合計ヒットに基づいています
時間44651ヒット、ヒットあたり25000イベント-モジュールヒットmsec％合計イベント/秒
intelppm 27457 128685 61％5334149
hal 12284 128685 27％2386447
ntkrnlpa 2868 128685 6％557174
win32k 525 128685 1％101993
alder9xp 427 128685 0％82954
tcpip 254128685 0％49345
NTFS 251 128,685 0％48762
afd 120128685 0％23312
RDPDD 109128685 0％21175
e1e5132 109 128685 0％21175
iaStor 97128685 0％18844
NDIS 39128685 0％7576
RDPWD 31128685 0％6022
fltMgr 26128685 0％5051
アモン12 128685 0％2331
termdd 10128685 0％1942
CLASSPNP 10128685 0％1942
ftdisk 7128685 0％1359
ipsec 3128685 0％582
Npfs 2 128685 0％388
USBPORT 2 128685 0％388
volsnap 2 128685 0％388
TDTCP 1 128685 0％194
rdbss 1 128685 0％194
ws2ifsl 1 128685 0％194
netbt 1 128685 0％194
ウォッチドッグ1 128685 0％194
PartMgr 1 128685 0％194
=================================== END OF RUN ============== ======================
次に、「ハードウェア割り込み」プロセスを読み込むドライバーを決定します。 Kernrate Viewログリストの最上位になり、コア占有率がパーセンテージの横に表示されます。 パーセンテージは、システム負荷の合計パーセンテージではなく、ドライバーによるサーバーコアの負荷パーセンテージを示すことに注意してください。
このドライバはIntelppm（Intelプロセッサパワーマネージャ）であると判断しました。 次-Googleがお手伝いします。 インターネットは大きく、強力で無制限です。 彼らはIntelppmの問題が発生することをすぐに認識しましたが、それほど頻繁ではありませんが、このような災害に直面したのは私たちだけではありませんでした。 結果の発見は遅かったわけではなく、問題自体を説明するだけでなく、それを解決する方法を示す記事もありました（元の記事の永続アドレスはこちら： http : //www.osp.ru/text/print/302/5818429.html ）
さらに、Stephen Doughertyの推奨に従って、intelppmはバッテリー電源がまったく使用されていないサーバーでは必要ないプロセッサ電源管理ドライバーであることを理解しています。 いくつかの解決策が提案されました：障害のあるドライバーの再インストール、更新、または停止。 どのオプションを選択するか-自分で確認してください。ここでは、Dohertyの元の推奨事項に従うことが論理的です。
私たちはレジストリに登りました。 Intelプロセッサドライバデータは、レジストリキーHKEY_LOCAL_MACHINE / SYSTEM / Current Control Set / Services / intelppmにあります。 intelppmドライバーを無効にするには、Startパラメーターの値を1から4に変更しました。もちろん、マイクロソフトの専門家はレジストリのバックアップコピーを作成することをお勧めしますが、私たちはロシア人であり、1つのパラメーターを1から4に変更するために必要なものです。
再起動は、完全な（！）サーバー負荷コールセンターコールでも、プロセッサ負荷が平均60〜70％であることを確認するのに役立ちました。
同時に、デバイスマネージャーは非常に興味深いように見えます。
苦情、潜入、叫び：「このデバイスのドライバーは無効になっています。 おそらく、必要な機能は別のドライバーによって実行されます。 （コード32）、「診断」ボタンをクリックして、このデバイスの診断ウィザードを開始します。「これは飛行の安全性には影響しません;-)
Nサーバーの構成とオペレーティングシステム
1 T1300 @ 1.66 1 GB RAM、Windows 2003 Standard Ed。 R2 SP1 32ビット
2 Intel Core Duo E8400 @ 3000 4 GB RAM、Windows 2003 Standard Ed.SP1 32ビット
3 Intel Pentium 4 3GHz 2 GB RAM、Windows 2003 Standard Ed。 SP2 32ビット
4 E3400 @ 2.60 2 GB RAM、Windows 2003 Standard Ed。 R2 SP2 32ビット
コミュニケーションの質に関する苦情に直面。 さらに、彼らはすべての電話について不平を言ったのではなく、「一部」について不平を言いました。 彼らは、VoIPテレフォニーの非常に特徴的な「クワキ」について不満を述べました。 「kwaks」が表示される理由は、負荷の増加に伴うコールセンターサーバーの1つ（最初）でのプロセッサの使用率の予測できない増加であることがすぐにわかりました。 これは、他のサーバーがそのような負荷にまったく気付かず、同じコール数でCPU負荷が増加しなかったという事実にもかかわらずです。 最初のサーバーが他のすべてのサーバーよりも著しく脆弱であるという事実にもかかわらず、そのような状況-プロセッサ使用率が100％に増加すること-は観察されるべきではありませんでした。
「ヘッドライトを拭く」、「車輪を蹴る」などの標準的な方法を採用したと言っても価値はないでしょう。最後に、コールセンターの設定もDBMSもサーバーの動作に影響を与えないという結論に達しました。 問題の本質を理解するための出発点は、プロセスリストのタスクマネージャーでは、どのプロセスもプロセッサー時間を消費しなかったという事実でしたが、パフォーマンスをモニターしている間、プロセッサー負荷履歴は20％の連続したカーネルプロセッサー負荷を示しました。
目標は、他のすべてのサービスに負荷がかかっていないときに、忙しいコアとは何かという質問に対する答えを得ることでした。 Microsoftの標準ユーティリティであるProcess Explorerは、リソースの主な消費者は「ハードウェア割り込み」であることを提案しました。 このような消費の理由をさらに分析するために、別の標準的なMicrosoftユーティリティであるKernrate Viewがダウンロードされました。 使用に関する推奨事項で説明されているように、コマンドラインは「C：\ Program Files \ KrView \ Kernrates \ Kernrate_i386_XP.exe >> log.txt」を実行し、しばらくしてCtrl-Cを押して停止しました。 次の形式の情報を含むlog.txtファイルを取得しました。
/ ================================
\ =============================== /
日付：2010/12/08時間：1:09:14
マシン名：RESERVCC
プロセッサー数：1
PROCESSOR_ARCHITECTURE：x86
PROCESSOR_LEVEL：6
PROCESSOR_REVISION：0e08
物理メモリ：1015 MB
ページファイル合計：2450 MB
仮想合計：2047 MB
PageFile1：\ ?? \ C：\ pagefile.sys、1524MB
OSバージョン：5.2 Build 3790 Service-Pack：1.0
WinDir：C：\ WINDOWS
Kernrateユーザー指定のコマンドライン：
Kernrate_i386_XP.exe
カーネルプロファイル（PID = 0）：ソース=時間、
25000イベント/ヒットのKernrateデフォルトレートを使用する
------------全体的な要約：--------------
P0 K 0：00：36.671（28.5％）U 0：00：09.671（7.5％）I 0：01：22.343（64.0％）DPC 0：00：29.484（22.9％）割り込み0：00：00.281（0.2％ ）
割り込み= 136809、割り込みレート= 1063 /秒
合計プロファイル時間= 128687ミリ秒
BytesStart BytesStop BytesDiff。
利用可能な物理メモリ、443772928、407339008、-36433920
利用可能なページファイル、2104172544、2093707264、-10465280
利用可能な仮想、2132660224、2131611648、-1048576
利用可能な拡張仮想、0、0、0
合計平均 レート
コンテキストスイッチ、609407、4736 /秒
システムコール、5078088、39661 /秒
ページフォルト、119817、931 /秒
I / O読み取り操作、11671、91 /秒
I / O書き込み操作、209479、1628 /秒
I / Oその他の操作、229216、1781 /秒
I / O読み取りバイト、39981700、3426 / I / O
I / O書き込みバイト、19240135、92 / I / O
I / Oその他のバイト、7130204725、31107 / I / O
-カーネルモードの結果：
-OutputResults：KernelModuleCount = 99
次の表の割合は、カーネルの合計ヒットに基づいています
時間44651ヒット、ヒットあたり25000イベント-モジュールヒットmsec％合計イベント/秒
intelppm 27457 128685 61％5334149
hal 12284 128685 27％2386447
ntkrnlpa 2868 128685 6％557174
win32k 525 128685 1％101993
alder9xp 427 128685 0％82954
tcpip 254128685 0％49345
NTFS 251 128,685 0％48762
afd 120128685 0％23312
RDPDD 109128685 0％21175
e1e5132 109 128685 0％21175
iaStor 97128685 0％18844
NDIS 39128685 0％7576
RDPWD 31128685 0％6022
fltMgr 26128685 0％5051
アモン12 128685 0％2331
termdd 10128685 0％1942
CLASSPNP 10128685 0％1942
ftdisk 7128685 0％1359
ipsec 3128685 0％582
Npfs 2 128685 0％388
USBPORT 2 128685 0％388
volsnap 2 128685 0％388
TDTCP 1 128685 0％194
rdbss 1 128685 0％194
ws2ifsl 1 128685 0％194
netbt 1 128685 0％194
ウォッチドッグ1 128685 0％194
PartMgr 1 128685 0％194
=================================== END OF RUN ============== ======================
次に、「ハードウェア割り込み」プロセスを読み込むドライバーを決定します。 Kernrate Viewログリストの最上位になり、コア占有率がパーセンテージの横に表示されます。 パーセンテージは、システム負荷の合計パーセンテージではなく、ドライバーによるサーバーコアの負荷パーセンテージを示すことに注意してください。
このドライバはIntelppm（Intelプロセッサパワーマネージャ）であると判断しました。 次-Googleがお手伝いします。 インターネットは大きく、強力で無制限です。 彼らはIntelppmの問題が発生することをすぐに認識しましたが、それほど頻繁ではありませんが、このような災害に直面したのは私たちだけではありませんでした。 結果の発見は遅かったわけではなく、問題自体を説明するだけでなく、それを解決する方法を示す記事もありました（元の記事の永続アドレスはこちら： http : //www.osp.ru/text/print/302/5818429.html ）
さらに、Stephen Doughertyの推奨に従って、intelppmはバッテリー電源がまったく使用されていないサーバーでは必要ないプロセッサ電源管理ドライバーであることを理解しています。 いくつかの解決策が提案されました：障害のあるドライバーの再インストール、更新、または停止。 どのオプションを選択するか-自分で確認してください。ここでは、Dohertyの元の推奨事項に従うことが論理的です。
私たちはレジストリに登りました。 Intelプロセッサドライバデータは、レジストリキーHKEY_LOCAL_MACHINE / SYSTEM / Current Control Set / Services / intelppmにあります。 intelppmドライバーを無効にするには、Startパラメーターの値を1から4に変更しました。もちろん、マイクロソフトの専門家はレジストリのバックアップコピーを作成することをお勧めしますが、私たちはロシア人であり、1つのパラメーターを1から4に変更するために必要なものです。
再起動は、完全な（！）サーバー負荷コールセンターコールでも、プロセッサ負荷が平均60〜70％であることを確認するのに役立ちました。
同時に、デバイスマネージャーは非常に興味深いように見えます。
苦情、潜入、叫び：「このデバイスのドライバーは無効になっています。 おそらく、必要な機能は別のドライバーによって実行されます。 （コード32）、「診断」ボタンをクリックして、このデバイスの診断ウィザードを開始します。「これは飛行の安全性には影響しません;-)
All Articles