sql >> データベース >  >> RDS >> Sqlserver

SQLServerのI/Oパフォーマンスの分析

    私がコンサルタントとして見ている最も一般的なパフォーマンスのボトルネックの1つは、不十分なストレージサブシステムのパフォーマンスです。ストレージのパフォーマンスが低下する理由はいくつかありますが、ストレージのパフォーマンスを測定し、何を測定および監視する必要があるかを理解することは、常に有用な演習です。

    I/Oサブシステムのパフォーマンスを測定する際に最も重要な3つの主要なメトリックが実際にあります。

    レイテンシ

    最初のメトリックはレイテンシーです。これは、I/Oが完了するのにかかる時間です。これは、応答時間またはサービス時間と呼ばれることがよくあります。測定は、オペレーティングシステムがドライブ(またはディスクコントローラ)に要求を送信したときに開始され、ドライブが要求の処理を終了したときに終了します。オペレーティングシステムがデータを受信すると読み取りが完了し、ドライブがデータを受信したことをドライブがオペレーティングシステムに通知すると書き込みが完了します。

    書き込みの場合、キャッシュポリシーとハードウェアによっては、データがドライブまたはディスクコントローラーのDRAMキャッシュに残っている場合があります。ライトバックキャッシングはライトスルーキャッシングよりもはるかに高速ですが、ディスクコントローラーのバッテリーバックアップが必要です。 SQL Serverを使用する場合は、可能な限り、ライトスルーキャッシュではなくライトバックキャッシュを使用していることを確認する必要があります。一部のベンダーのディスク管理ツールではデフォルトで無効になっているため、ハードウェアディスクキャッシュが実際に有効になっていることも確認する必要があります。

    1秒あたりの入出力操作(IOPS)

    2番目のメトリックは、1秒あたりの入出力操作(IOPS)です。このメトリックは、レイテンシーに直接関係しています。たとえば、1msの一定の遅延は、ドライブが1秒あたり1,000 IOを処理でき、キューの深さが1であることを意味します。キューにIOが追加されると、遅延が増加します。フラッシュストレージの主な利点の1つは、ディスクアクセスを遅くする電気機械的な可動部品がないという事実に加えて、複数のNANDチャネルに対して並列に読み取り/書き込みができることです。 IOPSは、実際にはキューの深さを遅延で割ったものに等しく、IOPS自体は、個々のディスク転送の転送サイズを考慮しません。キューの深さと転送サイズがわかっている限り、IOPSをMB /秒に、MB/秒をレイテンシに変換できます。

    シーケンシャルスループット

    シーケンシャルスループットは、データを転送できる速度であり、通常はメガバイト/秒(MB /秒)またはギガバイト/秒(GB /秒)で測定されます。 MB /秒単位のシーケンシャルスループットメトリックは、IOPSに転送サイズを掛けたものに等しくなります。たとえば、556MB/秒は135,759IOPS×4096バイトの転送サイズに相当しますが、135,759IOPS×8192バイトの転送サイズは1112MB/秒のシーケンシャルスループットになります。 SQL Serverにとって日常的に重要であるにもかかわらず、エンタープライズストレージでは、ストレージベンダーとストレージ管理者の両方によって、シーケンシャルディスクスループットが短期間で変更されることがよくあります。また、直接接続ストレージ(DAS)エンクロージャーまたはストレージエリアネットワーク(SAN)デバイス内の実際の磁気ディスクが非常にビジーであるため、完全な定格のシーケンシャルスループットを提供できないことも実際にはかなり一般的です。

    シーケンシャルスループットは、データベースの完全バックアップと復元、インデックスの作成と再構築、大規模なデータウェアハウスタイプのシーケンシャル読み取りスキャン(データがSQL Serverバッファープールに収まらない場合)など、多くの一般的なデータベースサーバーアクティビティにとって重要です。新しいデータベースサーバーのビルドで狙うパフォーマンスの目標の1つは、ドライブ文字またはマウントポイントごとに少なくとも1GB/秒のシーケンシャルスループットを実現することです。このレベル(またはそれ以上)のパフォーマンスを使用すると、データベースの専門家としての生活が非常に楽になります。これにより、一般的なデータベースの雑用の多くが非常に高速になり、大きなテーブルに数時間ではなく数秒または数分でインデックスを作成できる場合は、より頻繁にインデックスを調整する自由が得られます。

    SQL Server I/Oワークロードメトリック

    SQLServerとI/Oのパフォーマンスに関しては、時間をかけて測定および監視する必要のあることがいくつかあります。すべてのユーザーデータベースファイルとtempdbのワークロードの読み取りと書き込みの比率を知っておく必要があります。比率は、SQLServerのファイルタイプとワークロードによって異なります。 DMV診断クエリを使用してこれを判断できます。また、SQL Sentry Performance Advisorのディスクアクティビティビューを使用して、高レベルの全体像からディスクアクティビティのより完全なビューを簡単に取得することもできます。個々のファイルへ:

    SQL Sentry Performance Advisor:ディスクアクティビティ

    また、IOPSとシーケンシャルスループットの一般的なI/Oレートを測定する必要があります。 Windowsパフォーマンスモニター(PerfMon)では、読み取り/秒と書き込み/秒はIOPSを示し、ディスク読み取りバイト/秒とディスク書き込みバイト/秒はシーケンシャルスループットを表します。 PerfMonを使用して、平均ディスク秒/読み取りおよび平均ディスク秒/書き込みを測定する必要があります。これは、ディスクレベルでの読み取りおよび書き込み遅延です。最後に、DMV診断クエリを使用して、すべてのユーザーデータベースファイルとtempdbの平均ファイルレベルの読み取りおよび書き込みレイテンシを測定できます。

    I/Oパフォーマンスの測定方法

    Windows Resource Monitorの[ディスク]セクションを使用して、すべてのSQLServerデータベースファイルのいくつかの主要なディスクメトリックをすばやくリアルタイムで表示できます。さらに深く掘り下げると、PerfMonを使用して、前述の重要なパフォーマンスカウンターを測定および監視できます。新しいデータベースサーバーを使用して本番環境に移行する前に、ディスクベンチマークテストを実行して、I/Oサブシステムが実際に提供できるパフォーマンスの種類を判断する必要があります。これは実際にはそれほど難しくも時間もかかりませんが(適切なツールを使用している場合)、新しいデータベースサーバーをプロビジョニングしてテストすると忘れられることがよくあります。

    常に実行する必要がある最初のディスクベンチマークはCrystalDiskMark4.0です。これは、比較的新しいMicrosoftDiskSpdディスクベンチマークプログラムを使用するように最近書き直されました。 CDM 4.0のユーザーインターフェイスでは、テストファイルのサイズを幅広く選択できます。また、テスト実行のキューの深さとスレッド数を選択することもできます。これにより、サーバーのようなI / Oワークロードを取得でき、32を超えるキューの深さを処理できる新しいNVMeフラッシュストレージデバイスに適切にストレスをかけることができます。

    CrystalDiskMark 4.03 QD=32およびスレッド=1の結果

    図2:CrystalDiskMark 4.03 QD=32およびスレッド=4の結果>

    以前のバージョンのCDMとは異なり、SQL Serverの使用に最も関連する2つの行は、結果表示の中央にあります。これらは、キューの深さが深い(デフォルトでは32)4Kのランダムな読み取りと書き込み、および順次の読み取りと書き込みです。 CrystalDiskMark 4.0でストレージベンチマークテストを行った後、MicrosoftDiskSpdでさらに徹底的なテストを行う必要があります。今後の記事では、DiskSpdを使用してSQLServerのより完全なテストを行う方法について説明します。


    1. 世界のバックアップの日:知っておくべき4つの興味深いデータ損失の事実

    2. チーム内でOracleのストアドプロシージャを操作するためのツール?

    3. 常にnvarchar(MAX)を使用することに不利な点はありますか?

    4. ウェビナー:SQLServerでのクエリの進行状況の追跡