web-dev-qa-db-ja.com

SSDまたは仮想のSQL Server tempdb RAMディスクで一時テーブルのパフォーマンスを向上させます

月次ベースで、合計4日間実行される多くの一時計算があります。それほど多くのスクリプトを変更することはできないため、構成/ハードウェアソリューションを探しています。

背景

少なくとも10個のアプリケーションから情報のビットを作成しているため、これはETLプロセスではありません（したがって、これを計算または多くの更新ステートメントと呼びます）。この情報の組み合わせは、計算されたデータを最終的に通常のETLプロセス（SSIS）でDWHに保存する、より大きなプロセスの1ステージにすぎません。この計算段階が失敗した場合（サーバークラッシュ）、簡単に再起動できます。

問題

この計算が実行されているMSSQLサーバーには、2台のHDD-raid1しかありません。 1つのraid1はデータ、インデックス、tempdb用で、もう1つはログ用です。この計算では大量のI/Oが生成されるため、プロセス全体で数日かかります。サーバーには180 GBのRAM=があり、理論的にはデータ全体とこれらの計算結果が5 GBのメモリに収まる可能性があります。これは、データベース/リソースを間違った方法で使用していることを示しています。

考えられる解決策

そもそもI/Oを減らして、2番目のステップで必要なI/Oを処理する必要があると思います。ところで、サーバーはSQL Server 2014 Standard Editionです。

  1. Tempdbを仮想RAMディスク（約40GB）に移動します。つまり、メインI/Oをメモリに移動します。
  2. より多くの一時テーブルを使用して、サーバーのログ記録と回復時間を削減し、新しいRAMディスクを使用します（ログ記録は本当に少ないですか？）
  3. ログ、インデックス、重要なテーブルを新しいSSD RAID 5に配置します
  4. 他のすべてのデータを古いHDDドライブに置く

これは良いソリューションですか、それともSSD上の標準ソリューションtempdbも提案しますか？

sql-serversql-server-2014performancetempdbperformance-tuning
3
headgrowe

特定の行動方針に取り組む前に、まず、パフォーマンスの低下の原因を理解する必要があります。

計算プロセスが進行中の待機統計を見てください。それらを収集して分析する方法についての優れた出発点については、Paul Randalによる この記事 を確認してください。

システムdmv、sys.dm_io_virtual_file_statsプロセスのI/O要件を理解する。このコードを使用します。これは、10分間のアクティビティを示しています。

IF (COALESCE(OBJECT_ID('tempdb..#vfs_stats'), 0) = 0)
CREATE TABLE #vfs_stats
(
    run_num INT NOT NULL
    , database_id INT NOT NULL
    , file_id INT NOT NULL
    , sample_ms BIGINT NOT NULL
    , num_of_reads BIGINT NOT NULL
    , num_of_bytes_read BIGINT NOT NULL
    , io_stall_read_ms BIGINT NOT NULL
    , num_of_writes BIGINT NOT NULL
    , num_of_bytes_written BIGINT NOT NULL
    , io_stall_write_ms BIGINT NOT NULL
    , io_stall BIGINT NOT NULL
    , size_on_disk_bytes BIGINT NOT NULL
);

TRUNCATE TABLE #vfs_stats;

INSERT INTO #vfs_stats (run_num
    , database_id
    , file_id
    , sample_ms
    , num_of_reads
    , num_of_bytes_read
    , io_stall_read_ms
    , num_of_writes
    , num_of_bytes_written
    , io_stall_write_ms
    , io_stall
    , size_on_disk_bytes
)
SELECT 1
    , vfs.database_id
    , vfs.file_id
    , vfs.sample_ms
    , vfs.num_of_reads
    , vfs.num_of_bytes_read
    , vfs.io_stall_read_ms
    , vfs.num_of_writes
    , vfs.num_of_bytes_written
    , vfs.io_stall_write_ms
    , vfs.io_stall
    , vfs.size_on_disk_bytes
FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs;

WAITFOR DELAY '00:10:00';

INSERT INTO #vfs_stats (run_num
    , database_id
    , file_id
    , sample_ms
    , num_of_reads
    , num_of_bytes_read
    , io_stall_read_ms
    , num_of_writes
    , num_of_bytes_written
    , io_stall_write_ms
    , io_stall
    , size_on_disk_bytes
)
SELECT 2
    , vfs.database_id
    , vfs.file_id
    , vfs.sample_ms
    , vfs.num_of_reads
    , vfs.num_of_bytes_read
    , vfs.io_stall_read_ms
    , vfs.num_of_writes
    , vfs.num_of_bytes_written
    , vfs.io_stall_write_ms
    , vfs.io_stall
    , vfs.size_on_disk_bytes
FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs;

SELECT 
    DatbaseName = d.name
    , FileName = mf.name
    , SampleTime_ms =   s2.sample_ms            - s1.sample_ms
    , Reads =           s2.num_of_reads         - s1.num_of_reads
    , BytesRead =       s2.num_of_bytes_read    - s1.num_of_bytes_read
    , IOStallRead =     s2.io_stall_read_ms     - s1.io_stall_read_ms
    , Writes =          s2.num_of_writes        - s1.num_of_writes
    , BytesWritten =    s2.num_of_bytes_written - s1.num_of_bytes_written
    , IOStallWRite =    s2.io_stall_write_ms    - s1.io_stall_write_ms
    , IOStall =         s2.io_stall             - s1.io_stall
    , GrowthOnDisk =    s2.size_on_disk_bytes   - s1.size_on_disk_bytes
FROM #vfs_stats s1
    INNER JOIN #vfs_stats s2 ON s1.run_num = (s2.run_num - 1)
        AND s1.database_id = s2.database_id
        AND s1.file_id = s2.file_id
    INNER JOIN sys.databases d ON s1.database_id = d.database_id
    INNER JOIN sys.master_files mf ON s1.database_id = mf.database_id 
        AND s1.file_id = mf.file_id
ORDER BY d.name
    , mf.name;

ベースラインとして使用できるプロセスのパフォーマンスプロファイルをよく理解する必要があります。変更を行ったら、ベースラインパフォーマンスを変更した後のパフォーマンスプロファイルを比較して、変更による影響を理解できます。

パフォーマンスプロファイルを理解しないと、問題にハードウェアを投げて暗闇の中で撮影することになります。ただし、古い7200 rpmで回転するRustや古いXeonプロセッサのデータファイルなど、パフォーマンスの低いハードウェアを使用していることがわかっている場合は、この方法が適しています。完全な推奨事項として、すべてのデータベース（tempdb、およびデータデータベース）を、Nice高速SSDに置くことをお勧めします。 PCIe SSD、および十分なプロセッサ速度とメモリ帯域幅があることを確認します。

2
Max Vernon