当社には、ウェブサイトのステージングに使用する専用サーバー（テスト サーバー）があります。サーバーのパフォーマンスが非常に悪くなったため、定期的に再起動する必要があります。パフォーマンスが悪いときは、タスク マネージャーでプロセスとメモリをチェックしましたが、すべて正常に見えます。
当社ではコンテンツ管理システムを使用していますが、この CMS の管理セクションを使用するときに常にパフォーマンスの低下に気づきます。これは、CMS が行っている DB 呼び出しに関係しているのではないかと考えています。
これは実現可能でしょうか? これをテストする方法について他に何か提案はありますか?
前もって感謝します...
答え1
これは実現可能でしょうか?
はい。
これをテストする方法について他に何か提案はありますか?
パフォーマンス チェック。パフォーマンスは CPU だけの問題ではないことに注意してください。DB が問題だと思われる場合は、IO が制限されている可能性があります。この場合、ディスクのレイテンシ/アクティビティの割合が急上昇します。ディスク パフォーマンス カウンターをチェックします。特に IO が制限されている場合は、CPU は基本的に IO の完了を待機しているためプロセスにサービスを提供しないので、CPU は低くなります。
通常、データベースはより忙しくなると、かなりの IO 予算を必要とし、それはかなりのディスクを意味します。私は現在 6 枚の 10k RPM ディスクを使用しているデータベースを持っていますが、間もなく 8 枚にアップグレードされます (データ専用)。一般的な安価な専用サーバーは、多くの場合、非常に貧弱な IO 予算を持っています。低速で大規模なエンド ユーザー ディスク (数が少ない) では、高速なサブシステムは作成されません。これは、いくつかのシナリオでは非常にうまく機能しますが、最終的には過負荷になる可能性があります。
答え2
TomTom が言ったように、これはシステムが CPU ではなく IO にバインドされていることを示す兆候であることはほぼ間違いありません。根本的な原因は、CMS の背後にある DB の負荷の増加だけかもしれませんが、他の何かである可能性もありますが、いずれにしても、PerfMon には、ディスク サブシステムが原因かどうかを明確に判断できる便利なカウンターがいくつかあります。
\LogicalDisk\Avg. ディスク秒/読み取りおよび \LogicalDisk\Avg. ディスク秒/書き込み
これらは、読み取りおよび書き込み IO 操作の基本的なレイテンシ数値であり、低いほど良いです。これらの数値が約 15 ミリ秒を超えると、サーバーのパフォーマンスが著しく低下します。
\LogicalDisk\Disk バイト/秒と\LogicalDisk\Disk 読み取り/秒と これで、全体的なディスク スループットがわかります。これらのレートは、スループットのみが原因で、または読み取り/書き込みパターンの IOP 制限に達したために、ディスク サブシステムの最大容量を飽和させている可能性があります。ただし、予測可能な IO パターンがあることに 100% 確信が持てない限り、これらの値から重要なことを推測するのは難しい場合があります。ここで注意すべき特定の数値を示すのに本当に役立つ方法はありませんが、単一の SATA ディスクから 50 ～ 100 MBytes/秒以上が得られている場合は、ほぼ期待どおりです。より高速なサーバー ディスク (10k、15k、SSD) はこれを超える可能性があり、SAN 接続ストレージは十分なコストをかければ、ほぼ必要なものを提供できます。小さなランダム IO (DB 操作に典型的) の場合、この数値は常に低く、あまり意味がありません。
\LogicalDisk\ディスク書き込み/秒、\LogicalDisk\ディスク読み取り/秒、および\LogicalDisk\ディスク転送/秒 これらから、1 秒あたりの個別の IO 操作数と読み取り/書き込み比率がわかります。回転ディスクは、この点でかなり制限されています。7.2K SATA ディスクは 1 秒あたり約 70 ～ 80 IO を維持できますが、10K ディスクでは 100 ～ 150 の範囲に、15K では 200 以上になります。SSD では 1 桁か 2 桁高くなります。RAID グループでは、読み取りについてはこれがほぼ直線的に増加しますが、書き込みでは 2 ～ 5 のペナルティが発生します。たとえば、3 ドライブの RAID 5 パック (書き込みペナルティは 4) では、1 つのドライブよりも約 25% 少ない書き込み IO がサポートされます。
レイテンシが危険な領域 (15 ミリ秒超) まで増加しているときにこの数値が増加する傾向がある場合、報告された具体的な数値に関係なく、ディスクが IOPS 制限に達していることを強く示しています。
\LogicalDisk\分割IO/秒 これにより、複数の操作が発生する IO 要求の数がわかり、断片化が IO アクティビティにどの程度影響しているかがわかります。
PhysicalDisk: 現在のディスク キューの長さと PhysicalDisk: 平均ディスク キューの長さ。 これは、物理ディスク レベルで完了を待っている未処理の IO の数を示します。これが単一のディスクで 2 以上の場合、またはディスクが構成されている RAID グループ内のディスクの数を超える場合は、ディスクがタイムリーに完了できる以上の IO をディスクに押し込んでいる可能性があります。これはあまり問題にならないシナリオもありますが、低レイテンシのディスク IO を必要とするシステム (メモリ キャッシュでディスクの弱点をカバーできないデータベース) では、本当に問題になります。最初の値は瞬間的な値なので、一貫して高い場合、または %disk 時間カウンターに合わせて変化する場合にのみ心配してください。平均ディスク キューの長さが高すぎる場合は、間違いなく問題があります。
物理ディスク: % ディスク時間 % ディスク時間は、ディスクのビジー状態を示します。これが 100% に近づくと、すべての追加 IO がキューに入れられる傾向にあるため、そのディスクに依存する他の処理をシステムに実行させることが困難になります。100% を大幅に下回る数値でも、問題があることを示している可能性があります。この数値が高いか上昇傾向にあり、現在のディスク キューの長さが高い場合は、ディスクの容量を超える IO 負荷が明らかに示されています。この数値は実際には奇妙な方法で計算されるため、RAID パフォーマンスの分析にはあまり役立たない可能性があります。
このTechnetブログ記事これらのカウンターのいくつかと、それらを使用して問題を特定し、解決方法を確立できるシナリオについてさらに詳しく説明します。
答え3
ワーカー プロセスを頻繁にリサイクルするように Web アプリケーション プールを構成することを検討する価値はありますか?