web-dev-qa-db-ja.com

8CPUのSQLServerボックスでCPUの使用がそれほど非対称なのはなぜですか?

SQL Server2008を実行している8CPUデータベースサーバーのCPU使用率がまったくバランスが取れていないことに気づきました。

これは、しばらく前のランダムな日の1日の平均です。これは典型的で、一貫して非対称です。

9、15、10、21、18、21、14、9

(画像は本当に高いので、ここではサムネイルのみですが、フルサイズの画像を表示するにはクリックしてください)

常にほぼ正確かつ完全にバランスが取れている4 CPU Webサーバーと比較すると、奇妙な印象を受けました。

さて、これは専用サーバーなので、そこで実行されているのはSQL Server 2008(および私たちがかなり頻繁に使用する組み込みの全文索引付け)だけなので、わかりませんCPU使用率が非常に非対称になる理由。考え?

7
Jeff Atwood

ファイル/ファイルグループはどのように設定されていますか?

盗用します 自分

IOについてもう1つ考えてみましょう。最も頻繁に使用される最大のテーブルを、複数のファイルを含むファイルグループに設定するように注意しました。これによるパフォーマンスの向上の1つは、SQLがファイルグループ内の各ファイルにリクエストをスレッド化することです。したがって、BigOverUsedTableがFileGroup1にあり、FileGroup1に4つのファイルがあり、DBに8つのコアがある場合、実際には4つのコアを使用して「選択」を実行します。 BigOverUsedTableからの厄介なクエリを大量に処理します」-それ以外の場合は、1つのCPUのみを使用します。このMSDNの記事からこのアイデアを得ました:

http://msdn.Microsoft.com/en-us/library/ms944351.aspx

TFAから:

「ファイルグループは並列スレッドを使用してデータアクセスを改善します。テーブルに順次アクセスすると、システムはファイルごとに個別のスレッドを並列に作成します。システムが4つのファイルを含むファイルグループ内のテーブルのテーブルスキャンを実行する場合、4つの個別のスレッドを使用します。データを並列に読み取るスレッド。一般に、別々のディスクで複数のファイルを使用すると、パフォーマンスが向上します。ファイルグループ内のファイルが多すぎると、並列スレッドが多すぎてボトルネックが発生する可能性があります。」

このアドバイスにより、8コアマシンのファイルグループに4つのファイルがあります。それはうまくいっています。

編集:これは今、別の(おそらく)より良い答えを持っています。グラフのスケールはずれていました。よく見ると、uzbonesが指摘しているように、各プロセッサは実際には約20%ロードされています。

編集:4つのファイルを含むファイルグループにすべてのテーブルを配置しなかったため、複数のファイルファイルグループを使用すると役立つことが実際にわかります。 「単一ファイル」ファイルグループに対する大きなクエリは1つのCPUのみを使用しますが、4つのファイルファイルグループ内のテーブルに対するクエリは4つのCPUにヒットします。

9
Kyle Hodgson

スケールはすべてで異なりますが、4つのグラフのスパイクを除いて、平均はすべて約10〜25%になります。

9
uzbones

これをチェックしてください:

http://blogs.technet.com/mat_stephen/archive/2005/02/02/365325.aspx

SQLはほんの一握りのファイルにしか書き込んでおらず、各プロセッサは各ファイルを使用しています。

6
MathewC

私が最初にそのようなものをチェックするのはドライバーです。ネットワークチーミングとiSCSIMPIOドライバーが特定のコアに固執することで多くの問題が発生しました。 4コアで発生しているように見えるので、ここでは問題ではないと思います。通常、2コアでしか発生しません。こんなに広く見た人がいないか聞いてみます。

また、メモリの不一致があるNUMAボックスでも見ました。たとえば、コアの半分は最大16 GBのRAMに接続され、残りは最大8に接続されています。それに関する面白い情報が必要な場合は、Google for IBM x460NUMAを使用してください。 460および関連モデルを使用すると、複数のサーバーをデイジーチェーン接続して大きな鉄を作成できます。これは、スケールアップとブログエントリの比較に関連しています。彼らは素晴らしいマシンです。

3
Brent Ozar

CPUキャッシュのフラッシュは非常にコストがかかるため、カーネルはそれを絶対に回避しようとします。

(注:少なくともLinuxはそうです。Windowsが同じ振る舞いをしていなかったら、私は驚きます)

0
David Pashley