web-dev-qa-db-ja.com

SSD上のSQL Serverが遅いようです

最近、SQL ServerをSSDに移動しましたが、パフォーマンスの向上はそれほど大きくありません。

SQLIOは大幅な向上（15-100倍速い）を示し、最大6GB/sのシーケンシャル読み取り/書き込み速度を実現します。

しかし、単純なクエリを実行すると、次のようになります。

select * 
into table2  
from table1

およそ60MB/sのようになります。 2GBテーブルが完了するまで30秒かかります。

これは正常ですか？このような単純なクエリでSSDの平均速度と見なされる速度はどれくらいですか？ RAM問題、50GBのRAMであるとは思わないでください。

sql-serverperformancessd
1
Atomix

問題が解決しました。そのVMにIO制限がありました。

SQLIOに関しては、hyper-vにありました。

https://social.technet.Microsoft.com/Forums/Azure/en-US/b8e1674d-f1c7-4e46-b1f1-09fb0d75d82e/strange-blazingfast-io-performance-inside-hyperv-vm?forum= winserverhyperv

https://serverfault.com/questions/287311/does-sqlio-lie-when-run-from-a-hyper-v-guest-on-a-vhd

1
Atomix

SQL Serverのバージョンに応じて、クエリのパフォーマンスに影響を与える可能性があるさまざまな要素があります。

  1. SQL Serverのバージョン：SQL Server 2014では、TABLOCKヒントを使用すると、ヒープテーブルへの並列挿入が可能になります（SELECT INTOのみ）。 SQL Server 2016はこれを拡張し、INSERT SELECTを使用してヒープまたはクラスター化列ストアインデックスに並列挿入できるようにします
  2. SQL Server Edition：Enterprise Editionは、先読みに対して、Standard Editionよりも優れたIOを発行します。
  3. 断片化：SSDにはシークレイテンシはありませんが、大規模なシーケンシャルリードで最高のパフォーマンスを発揮します。高レベルのフラグメント化は、先読み読み取りの効果を妨げます。
  4. フィルファクター：5％のフィルファクターでインデックスを再構築すると、ディスク上で20倍大きくなるため、20倍以上IOそれを読み取るためです。新しく再構築されたインデックスは、両方の断片化から最適になります。先読みの視点。

待機統計分析により、現在のボトルネックが何であるかがわかります。 PAGEIOLATCH_Sが表示される場合は、読み取りが問題です。ソーステーブルでクラスター化インデックスを再構築します。 IOボトルネックが表示されない場合は、CPUにバインドされていると考えられます。1つのCPUが100％になるようにしてください（クエリがシングルスレッドで実行されている場合）。 TABLOCKヒントを追加して、並列処理を試みます。

SELECT INTOは一括ログ操作であり、TEMPDBを使用しないため、ログファイルまたはtempdbのファイル配置を調べる必要はありません。

0
StrayCatDBA