この「ひざまずくパフォーマンスチューニング」シリーズの続きでは、ソリッドステートディスク（SSD）と、SQLServer環境での使用で発生する問題のいくつかについて説明します。 SSDの詳細については、このWikipediaの記事をご覧ください。
SSDはSQLServerのパフォーマンスのために何をしますか？
SSDには可動部品がないため、読み取りまたは書き込みが発生しても、I/O遅延はほとんどありません。回転するドライブの遅延は、次の2つの原因から発生します。
- ディスクヘッドをディスク表面の正しいトラックに移動する（シーク時間と呼ばれる）
- ディスクがトラック上の正しいポイントに回転するのを待っています（回転待ち時間と呼ばれます）
これは、I / Oボトルネックがある場合、SSDがパフォーマンスを大幅に向上させることを意味します。
とても簡単です。
言及する価値のある少し複雑な問題がありますが、この記事の範囲を超えて詳細に説明します。ドライブが実際にいっぱいになると、SSDのパフォーマンスが低下し始める可能性があります（AnandTechのこの記事で詳細に調査および説明されています）。 SSDドライバーがウェアレベリング（SSD内のNANDセルの寿命を延ばす）を支援するために必要なシステムメモリもある場合がありますが、これはベンダーによって異なります。それで十分です–SQLServerのものに戻ります。
悪いインターネットアドバイスを避ける
インターネット上でSQLServerとSSDに関して2ビットの非常に貧弱なアドバイスがあります。
1つ目は、SSDに何を配置するかについてです。ここで、アドバイスは常にtempdbとトランザクションログをSSDに配置することです。トランザクションログとtempdbは一般にシステムのボトルネックであるため、一見良いアドバイスのように聞こえます。
しかし、そうでない場合はどうなりますか？
ワークロードが読み取られる可能性があります。ほとんどの場合、トランザクションログはワークロードのボトルネックにはならないため、SSDに配置すると高価なSSDが無駄になる可能性があります。
tempdbはあまり使用されない可能性がありますワークロードによっては、SSDに搭載することは、高価なSSDの無駄になる可能性があります。
SQL Server環境のどの部分をSSDに移行するかを検討するときは、I/Oのボトルネックがどこにあるかを調査する必要があります。これは、先週投稿したsys.dm_io_virtual_file_stats DMVを使用して、インスタンス上のすべてのデータベース内のすべてのファイルのI/Oレイテンシーのスナップショットを提供するコードを使用して非常に簡単に実行できます。レイテンシーの数値を理解し、それらを良い値/悪い値と比較するために、私が特にtempdbとトランザクションログのI/Oレイテンシーについて行ったこの長い投稿を読んでください。
そして、レイテンシが高い場合でも、ひざまずいて、パフォーマンスの低いファイルをSSDに移動することが唯一の解決策であると考えないでください。
- データファイルの読み取りレイテンシについては、読み取りが非常に多く発生する理由を調査してください。ここで説明します。
- ログファイルの書き込みレイテンシについては、ログのパフォーマンスとログに記録される内容を調整するためのすべての方法を検討してください。ここ、ここ、そしてここでそれをカバーします。
考えられる最悪のケースは、多数のSSDが提供され、インターネットのアドバイスに従ってtempdbとログファイルをSSDに移動しても、ワークロードのパフォーマンスが向上しない場合です。これは、経営陣がより高価なSSDを提供することを奨励するものではありません。
悪いアドバイスの2つ目は、インデックスの断片化に関するものです。SSDは非常に高速であるため、SSDを使用するときにインデックスの断片化について心配する必要はありません。
なんてナンセンスだ！
私がその悪いアドバイスに反論する3つの方法があります：
- SSDは、インデックスの断片化の原因を止めることはできません。ランダムな挿入または行サイズの増加のために空き領域を必要とするページからのページ分割。ページ分割により、データ/ログファイルの保存場所に関係なく、同じ量のトランザクションログ、リソース使用量、および潜在的なスレッド待機が生成されます。
- インデックスの断片化には、ページ密度の低い（つまり、多くの空の空きスペースがある）多くのデータ/インデックスページが含まれます。高価なSSDに多くの空きスペースを保存したいですか？ SSDはここではまったく役に立ちません。
- 同僚のJonathanKehayiasは、拡張イベントを使用して、インデックスの断片化に関するI / Oパターンについて詳細な調査を行い、特にこの悪いアドバイスに対処しました。SSDを使用すると、インデックスの断片化によってパフォーマンスが低下することがわかりました。彼の長い投稿はここで読むことができます。
SSDがインデックスの断片化を回避する唯一のことは、読み取りを高速化することです。そのため、インデックスの断片化が存在する場合、インデックス範囲スキャンのパフォーマンスの低下は少なくなりますが、上記のポイント3は、依然として低下があることを示しています。
SSDは、SQLServer環境でのインデックスの断片化の処理方法や防止方法を変更しません。
データを確実に保護する
SSDの使用をめぐる人々が犯している重大な罪の1つは、SSDの1つだけを使用していることです。ドライブが1つしかない場合、どのRAIDレベルを使用していますか？零。 RAID-0は冗長性をまったく提供しません。
SSDを使用する場合は、RAID-1（ミラーリング）構成で少なくとも2つ使用する必要があります。トレードオフとしてシステムの可用性を犠牲にしている場合は、パフォーマンスを向上させる意味はありません。
少なくとも2つのSSDを使用することで、SSDカードがWindowsに2つのドライブを提供することがあります。したがって、2つのドライブにWindowsミラーボリュームを作成することは、物理的に離れた2つのSSDにRAID-1を作成することと同じですか？
いいえ、ちがいます。それでも1つの物理SSDであり、冗長性はありません。 SSDカードの半分が故障するのを見たことがありますか？いいえ、どちらも私は持っていません。正しく実行し、そのうちの2つを使用して、データの真の冗長性を確保してください。
私が得たもう1つの反発は、それらがSSDであり、回転するドライブではないため、失敗することはないということです。それは間違っている。 SSDは、回転するドライブと同じように故障する可能性があります。個人的には、ラボ環境でのテスト中に2つのエンタープライズグレードのSSDが故障するのを見てきました。 StorageReview.comのこの記事によると、コンシューマーグレードのSSDのMTBFは200万時間であるのに対し、コンシューマーグレードのスピニングドライブでは150万時間であり、エンタープライズグレードのドライブでも同様の結果が期待できますが、SSDは失敗します。
概要
SSDに何を置いても、パフォーマンスが向上するという考えに陥らないでください。慎重に選択する必要があります。また、SSDを使用するときにインデックスの断片化を無視することについてのナンセンスを信じないでください。
SSDはパフォーマンスを向上させるための非常に便利な方法ですが、SSDを正しく使用し、適切な場合にのみ使用することで、コストの面で企業の投資収益を最大化する必要があります。
シリーズの次の記事では、ニージャークパフォーマンスチューニングのもう1つの一般的な原因について説明します。それまでは、トラブルシューティングを行ってください。