私は、RAID 6 でセットアップされた SSD を備えた SAN を使用して Windows VMWare プラットフォーム上で SQL Server を実行し、サーバーのバックアップに Veeam を使用し、SQL Server のバックアップに LiteSpeed を使用している環境を持っています。
過去 1 年間に何度か、データベースの速度が極端に低下し、平均ディスク キューの長さは高いのに、ディスク バイト/秒が想定よりも大幅に低いという問題が発生しました。
これは、データベース サーバーのパフォーマンス モニターです。この問題が発生すると、平均ディスク キューの長さは常に数百の範囲にあり、ディスク バイト/秒は 5 ～ 15 MB/秒程度に留まります。通常の操作中 (この問題が発生していない場合)、ディスク バイト/秒は 900 MB/秒程度まで上昇します。
この問題が起こり始めてから、スイッチを含む SAN ハードウェアを交換しました。しかし、新しいハードウェアでも問題は解決しません。
私の理論では、これは SQL Server の問題ではないとしています。SQL Server がディスク I/O を飽和させていることが問題であれば、ディスク バイト/秒がはるかに高くなるはずです。しかし、この問題が発生すると、ディスク バイト/秒は常に非常に低くなります。
おそらく、データベース サーバーで実行されているか、同じ VMWare/SAN を使用している別のサーバーで実行されているバックアップ ソフトウェアが原因だと思いましたが、この問題が発生している間は、サーバー バックアップも SQL Server バックアップも実行されていないようです。
最後に、これは VMWare の問題だと思いましたが、VMWare に連絡しましたが、今のところ解決できていません。
データベース サーバーを再起動すると、問題は解決します。問題が 1 日以内に再発することもありますし、数か月間再発しないこともあります。問題が発生するたびに、データベースで実行されている通常のワークロード以外には何も認識されません。
ディスクのスループットが本来の能力の約 1% まで低下するというこの問題の原因は何でしょうか?
答え1
HDD は、作業キューが長くなるほど遅くなり、逆に遅くなると遅くなります。HDD に投入できる IOPS の数は非常に限られています (グレードと RPM に応じて、およそ 40 ～ 200)。その点を超えて要求が増加すると、パフォーマンスはさらに低下します。
HDD アレイを作成すると、アレイ全体の読み取り IOPS の合計数は増加しますが、通常は個々の IOPS を単純に合計するよりも少なくなります。書き込み IOPS はより複雑で、RAID レベル、キャッシュなどにも大きく依存します。
それ以上の場合は、SSD と適切なコントローラーが必要です。
答え2
すでに SSD を使用しているので、問題は私が経験した問題と似ており、SSD で TRIM が適切に処理されていない可能性があります。SSD 上のデータ ブロックの消去は瞬時に行われるわけではなく、再利用のためにブロックを準備するプロセスは遅い場合があり、速度低下の原因となる可能性があります。空きブロックと準備済みブロックが使い果たされると、新しいブロックが準備されるときにアレイの速度が大幅に低下する可能性があります。SAN がこれらが SSD であることを認識していること、およびバックグラウンド TRIM が有効になっていることを確認してください。