io_stall_writes_msがtempdbでこれほど高いのはなぜですか？

ユーザーとシステムのデータファイルは同じディスクドライブにあります。（io_stall_write_ms /（1.0 + num_of_writes））は、ユーザーファイルでは2未満ですが、tempdbファイルは通常400を超えています。いくつかのサーバーでは、tempdbに書き込むのに時間がかかる理由があるので興味があります通常のデータベースデータファイルよりも。

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

ありがとうございました、

短い答え：高いIOストールを確認すること自体が問題になる場合とそうでない場合があります。問題がある場合は、詳細を調べて確認する必要があります。はい、少し高いようですが、あなたは苦しんでいますか？もしそうなら、それはおそらくIOシステムがロード権を処理していないためです（1つのドライブまたは他の何らかの理由ですべてを持っているために処理できないため）、またはTempDBで多くのことをしている（最初の問題を変更する- IOパフォーマンス-おそらく簡単で効率的な修正ですが、最初に問題があるかどうかを判断します）

より長い議論/回答：

ここでは、2つの質問があります-

1.）IOストールが多い場合はどうすればよいですか？

最初に、「高い」は見る人の目にあります。10人のDBAにIOストールの「高すぎる」と尋ねると、おそらく2〜3の異なる答え、5〜6の「それは依存している」と1つの空の凝視が返されます。私の想定では、特に他のDBが平均ストール時間で2ミリ秒以下の場合、平均400ミリ秒はここでは高すぎる可能性があります。

どのデータベースで高ストールが発生しているかに関係なく、同じ方法でアプローチする必要があります。IOストールは、そのように聞こえます...予想よりも時間がかかるIOリクエスト..ストール。これらが起こります。これらは、リソースが共有され、有限のリソース（実際にはすべてのシステム）が存在するシステムで常に発生します。ストールがパフォーマンスの問題になるか、その原因になると、問題になります。したがって、監視の予防的な部分として、またはトラブルシューティングを行っているパフォーマンスの問題が発生しているために、ここを探していると思います。また、IOストールだけで迷子になりたくありません。全体像ではなくパズルの一部を見ています。SQLが最後に再起動されてから、常に統計情報やファイル統計情報を確認するのは面倒な場合があります。これは、常にメンテナンスウィンドウや高負荷ウィンドウが表示されるためです。そのため、全体像を確認してください。

しかし、ディスクパフォ​​ーマンスの問題があると思われる場合、またはこのようなクエリで何かがわかる場合、通常、次のようなプロセスに従います。

1. サーバーの待機統計を確認します。@swasheck は、以下の回答のコメントとして素晴らしいリンクを共有しました。これにより、SQL Serverの待機統計の確認と分析に関するPaul Randalの投稿に移動できます。そこに行きます。どんな待ちが待っていますか？あなたはIOのパフォーマンスに関連する待機ご覧ください（PAGEIOLATCH_*、IO_COMPLETION、WRITELOGなど、？）。これを行うと、IOストールと同様に、IO関連のパフォーマンスの問題があることを示す別の兆候になります。ただし、ここでは別の形式の同意が得られます。
2. IOパフォーマンスを見てください。特に、perfmonの内部Physical Disk:Avg Disk Sec/ReadとAvg Sec Disk Sec/Writeカウンターを見てください。これらはレイテンシを測定します。パフォーマンスログファイルに保存された期間にわたってこれらのカウンターを監視します。平均については何を見ましたか？0.020秒（20ミリ秒）を超える数値が表示される場合、これが問題になる可能性があります。平均値が40〜50ミリ秒を超える場合は、問題をより明確に示しています。あなたのスパイクも見てください？彼らはどれくらいの高さで、どのくらい続くのでしょうか？数百ミリ秒にスパイクが発生し、数十秒または数十秒以上続く場合や、頻繁に発生する場合は、ワークロードのIOパフォーマンスに問題がある可能性が高くなります。
3. IO設定を見てください。それは何ですか？ローカルディスク？さん？ストレージアレイ？全体を通してどのようなIOPがありますか？あなたがやろうとしていることで十分ですか？ワークロードのIOが小さすぎる可能性があります。物理的なスピンドル、RAID設定などだけを見るのではなく、ディスクへのパスを見てください。他の多くのトラフィックと共有している単一の1GBリンクを介してすべてをプッシュしていますか？ストレージの観点からディスクパフォ​​ーマンスメトリックを確認できますか。

（注：この待機統計分析とperfmon分析では、さまざまな期間と使用タイプを確認します。夜間の使用統計は日中と異なりますか？バッチ処理ウィンドウ？多数のインデックスを再構築するメンテナンスウィンドウですか？これらの各期間中にこれらのツールを見て、それぞれについて何を見ているかを理解してください）

ここで別のIOパフォーマンスの考慮事項-

• システムDBとユーザーDBは共有されていると言いました。この生産ですか？もしそうなら、それは常に最良のシナリオではありません。同じドライブでログファイルとデータファイルも共有していますか？それは最良のシナリオでもありません。このストレージを共有するものは何ですか？スピンドルとRAIDグループとディスクを心配していて、誰が最高のパフォーマンスのディスクを得るかを決定しなければならない世界では、私は（一般的な経験則として..しかし、これは真実である傾向があります）、TempDBに最速かつ最も専念し（詳細は以下）、ログファイル、データファイルの順に進みます。NetApp、Dell Equal Logic、EMC VNXなどのデバイスに大きなディスクの山がある世界では、

2.）TempDBの方が高い理由は何ですか？

したがって、TempDBはデータベースであり、先ほど説明した他のデータベースと同様にIOストールが発生する可能性があります。しかし、TempDBの読み取りが高くなる理由は何ですか？（網羅的ではありません。編集、その他の回答やコメントへの追加や考えを歓迎します）-

1. あなたのコードのために-あなたは意図的にコードでTempDBを多く使用していますか？多くの一時テーブルとテーブル変数が作成および破棄されましたか？このようにTempDBで多くのことをしていますか？それは必ずしも悪いことでも良いことでもありませんが、それを見て、意図的なTempDBの使用パターンを理解するかもしれません。
2. TempDBは共有の主力製品です。TempDBは、ユーザー定義の一時オブジェクトと、SQLインスタンス全体で使用されるさまざまな作業テーブルと操作の一時スペースとして使用される1つのデータベースです。ユーザーDBはいくつありますか？一般的にどのようなワークロードが見られますか？TempDBは、共有するすべてのものの1つのリソースです。
3. 効率の悪いクエリと不十分なメモリ-インデックスを十分に使用していないクエリや、大規模なスキャンおよびソート操作を行っているクエリがある可能性があります。大規模なハッシュ操作、およびサーバー上のメモリはこれらに対して十分ではありません。これらの操作は、背後で作業テーブルとしてTempDBに「流出」します。これは、クエリプランとインデックス作成またはクエリチューニングを見ることで回避できる場合があります。時々それが起こります（倉庫のワークロードではもっとそうです）。十分なメモリがある場合、これで解決できますが、これらのクエリが時々流出する可能性があります。これも見てください。
4. システムでかなりの数の更新を行うRead Committed Snapshot Isolationレベルを使用していますか？これにより、TempDBアクティビティが増加することもあります。

重要なのは、TempDBがさまざまな方法で使用されていることです。これは、最も忙しいデータベースではなくても、最も忙しいデータベースの1つであると考えてもまったく驚きません。また、クライアントのサイトにあるすべてのデータベースの中で最も多く、平均的なストールが多いと思っても、驚かない。それは時々そのワークロードの性質です。ここで言及したことのいくつかを見ると、これらの数値が問題を示しているかどうか、もしそうなら、それをより深く解決する方法を判断するのに役立ちます。

TempDBは、インスタンス上のすべてのデータベース間で共有されます。そのため、特定のページ（SGAM、GAM、およびPFS）についてTempDB内で競合が発生することがあります。簡単に言えば、これらのページは、TempDBでこれまでに使用されたものと、新しい使用のために使用可能なスペースを追跡します。

通常、これは、TempDBに複数のデータファイルを追加することで対処されます。正しい数についてはいくつかの異なる哲学がありますが、すべてがあなたが複数持っていることに同意します。

実行するクエリは次のとおりです...

これは、TempDBにあるファイルの数とその場所を示します。

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

これにより、CPUとコアの数が表示されます。

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

これにより、NUMAノードあたりのNUMAノードとコアの数が表示されます。

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

これは、TempDBで待機しているページを示します。

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

ページ競合の問題についてもう少し詳しく説明する記事を次に示します。

さて、哲学の部分は... :-)

私自身、SMPシステムを使用している場合、合計コアの半分のファイルだけが必要です。

私は上だ場合のNUMAシステム、そして私はできるだけ多くのファイルとして必要NUMAノードあたりのコア。

ただし、TempDBに4つを超えるファイルを追加しても、改善が見られることはめったにありません。そのため、通常は4から始め、リンク先の記事で説明されているように競合を監視します。

問題が引き続き発生する場合は、さらに2つ追加します。もう一度確認して追加し、競合が解消するまで繰り返します。