3

シングルスレッド版の説明:

  1. プログラムは質問のリストを収集します。
  2. 質問ごとに模範的な回答を取得し、スコアリング モジュールでそれぞれを実行します。
  • スコアリング モジュールは、多数の (読み取り専用) データベース クエリを作成します。
  • シリアル処理、単一データベース接続。

質問リストをチャンクに分割し、それぞれに対してスレッドを作成することにより、上記のプログラムをマルチスレッド化することにしました。

各スレッドは独自のデータベース接続を開き、独自の質問リスト (6 つのスレッドごとに約 95 の質問) を処理します。アプリケーションは、すべてのスレッドが終了するのを待ってから、結果を集計して表示します。

驚いたことに、マルチスレッド バージョンはほぼ同じ時間で実行され、17 秒ではなく約 16 秒かかりました。

質問:

個別の接続を使用して個別のスレッドで同時にクエリを実行する場合に期待されるようなパフォーマンスの向上が見られないのはなぜですか? マシンには 8 つのプロセッサがあります。

SQL Server は、単一のアプリケーションからのクエリを同時に処理しますか、それとも (または .net 自体) クエリをシリアル化しますか?

何かが誤って構成されている可能性があり、それにより高速化される可能性がありますか、それとも単に SQL Server を計算限界まで押し上げている可能性がありますか?

現在の構成:

Microsoft SQL Server Developer Edition 9.0.1406 RTM
OS: Windows Server 2003 Standard
プロセッサ: 8
RAM: 4GB

4

6 に答える 6

3

これは暗闇の中のショットですが、共有リソース (レコード) のロックによりデータベース内で自分自身をシリアル化するため、パフォーマンスの向上は見られないに違いありません。今、小さな活字のために。

あなたの C# コードは実際には正しく、実際には別々のスレッドを開始し、各クエリを並行して発行していると思います。問題はありませんが、さまざまな理由で、多くの人がその主張をしており、コードが実際にクライアントでシリアル化されているのを見てきました。サーバーを監視してこれを検証する必要があります (プロファイラーを使用するか、sys.dm_exec_requests および sys.dm_exec_sessions を使用します)。

また、クエリの重みは同じだと思います。つまり、15 秒持続するスレッドが 1 つと、100 ミリ秒持続するスレッドが 5 つないということです。

あなたが説明する症状は、詳細が不足しているため、各スレッドの開始時に、何らかのリソースで X ロックを取得する書き込み操作があることを示しています。最初のスレッドがリソースを開始してロックし、他の 5 つのスレッドが待機します。最初のスレッドが完了し、リソースを解放してから次のスレッドがそれを取得し、他の 4 つのスレッドが待機します。そのため、最後のスレッドは他のすべての 5 の実行を待機する必要があります。これは、sys.dm_exec_requestsを見て、リクエストをブロックするものを監視することで、トラブルシューティングが非常に簡単になります。

ところで、Asynchronous Processing=true の使用を検討し、BeginExecuteReader などの非同期メソッドに依存して、クライアント側スレッドのオーバーヘッドなしで実行中のコマンドを並行して起動する必要があります。

于 2009-05-21T22:14:03.333 に答える
1

プロセスの実行中にタスクマネージャーを確認するだけです。100% の CPU 使用率を示している場合は、CPU バウンドです。それ以外の場合は、その IO バウンド。

ハイパースレッディングの場合、50% の CPU 使用率は 100% の使用率とほぼ同じです!

うわー、私はスレッドがどれほど古いかわかりませんでした。他の人が見ているために応答を残すことは常に良いことだと思います。

于 2009-11-13T22:02:25.957 に答える
0

スレッドが接続を共有することは可能ですか? これを実行すると複数の SPID が作成されることを確認しましたか (sp_who)?

于 2009-05-21T21:10:23.103 に答える
0

私の最初の傾向は、ほとんど機能しないスレッドの IO 問題を解決しようとしているということです。IO は IO であり、スレッドが増えてもパイプは増えません。すべての質問とその回答を 1 つのバッチでダウンロードし、そのバッチを複数のスレッドでローカルに処理する方がよいでしょう。

そうは言っても、速度低下の原因となっている db ロックが発生している可能性があります。読み取り専用クエリについて話しているので、クエリで with (nolock) ヒントを使用してみて、それが役立つかどうかを確認してください。

SQL サーバーの処理に関しては、SQL サーバーは、構成で許可されている最大接続数まで、できるだけ多くの接続を同時に処理しようとすることを理解しています (接続ごとに一度に 1 つのステートメント)。あなたが見ている種類の問題は、ほとんどスレッドの問題ではなく、ほとんどの場合、ロックまたは IO の問題です。

于 2009-05-21T21:04:10.683 に答える
0

task_address で sys.dm_os_workers、sys.dm_os_tasks、および sys.dm_exec_requests に対して結合クエリを実行しました。結果は次のとおりです (一部の興味のない / ゼロ値のフィールドは除外され、あいまいさを解決するために ex または os で始まるフィールドもあります)。

-COL_NAME-  -Thread_1-  -Thread_2-  -Thread_3-  -Thread_4-

task_state  SUSPENDED   SUSPENDED   SUSPENDED   SUSPENDED
context_switches_count  2   2   2   2
worker_address  0x3F87A0E8  0x5993E0E8  0x496C00E8  0x366FA0E8
is_in_polling_io_completion_routine 0   0   0   0
pending_io_count    0   0   0   0
pending_io_byte_count   0   0   0   0
pending_io_byte_average 0   0   0   0
wait_started_ms_ticks   1926478171  1926478187  1926478171  1926478187
wait_resumed_ms_ticks   1926478171  1926478187  1926478171  1926478187
task_bound_ms_ticks 1926478171  1926478171  1926478156  1926478171
worker_created_ms_ticks 1926137937  1923739218  1921736640  1926137890
locale  1033    1033    1033    1033
affinity    1   4   8   32
state   SUSPENDED   SUSPENDED   SUSPENDED   SUSPENDED
start_quantum   3074730327955210    3074730349757920    3074730321989030    3074730355017750
end_quantum 3074730334339210    3074730356141920    3074730328373030    3074730361401750
quantum_used    6725    11177   11336   6284
max_quantum 4   15  5   20
boost_count 999 999 999 999
tasks_processed_count   765 1939    1424    314
os.task_address 0x006E8A78  0x00AF12E8  0x00B84C58  0x00D2CB68
memory_object_address   0x3F87A040  0x5993E040  0x496C0040  0x366FA040
thread_address  0x7FF08E38  0x7FF8CE38  0x7FF0FE38  0x7FF92E38
signal_worker_address   0x4D7DC0E8  0x571360E8  0x2F8560E8  0x4A9B40E8
scheduler_address   0x006EC040  0x00AF4040  0x00B88040  0x00E40040
os.request_id   0   0   0   0
start_time  2009-05-26 19:39    39:43.2 39:43.2 39:43.2
ex.status   suspended   suspended   suspended   suspended
command SELECT  SELECT  SELECT  SELECT
sql_handle  0x020000009355F1004BDC90A51664F9174D245A966E276C61  0x020000009355F1004D8095D234D39F77117E1BBBF8108B26  0x020000009355F100FC902C84A97133874FBE4CA6614C80E5  0x020000009355F100FC902C84A97133874FBE4CA6614C80E5
statement_start_offset  94  94  94  94
statement_end_offset    -1  -1  -1  -1
plan_handle 0x060007009355F100B821C414000000000000000000000000  0x060007009355F100B8811331000000000000000000000000  0x060007009355F100B801B259000000000000000000000000  0x060007009355F100B801B259000000000000000000000000
database_id 7   7   7   7
user_id 1   1   1   1
connection_id   BABF5455-409B-4F4C-9BA5-B53B35B11062    A2BBCACF-D227-466A-AB08-6EBB56F34FF2    D330EDFE-D49B-4148-B7C5-8D26FE276D30    649F0EC5-CB97-4B37-8D4E-85761847B403
blocking_session_id 0   0   0   0
wait_type   CXPACKET    CXPACKET    CXPACKET    CXPACKET
wait_time   46  31  46  31
ex.last_wait_type   CXPACKET    CXPACKET    CXPACKET    CXPACKET
wait_resource               
open_transaction_count  0   0   0   0
open_resultset_count    1   1   1   1
transaction_id  3052202 3052211 3052196 3052216
context_info    0x  0x  0x  0x
percent_complete    0   0   0   0
estimated_completion_time   0   0   0   0
cpu_time    0   0   0   0
total_elapsed_time  54  41  65  39
reads   0   0   0   0
writes  0   0   0   0
logical_reads   78745   123090  78672   111966
text_size   2147483647  2147483647  2147483647  2147483647
arithabort  0   0   0   0
transaction_isolation_level 2   2   2   2
lock_timeout    -1  -1  -1  -1
deadlock_priority   0   0   0   0
row_count   6   0   1   1
prev_error  0   0   0   0
nest_level  2   2   2   2
granted_query_memory    512 512 512 512

すべてのクエリのクエリ プラン プレディクターは、いくつかのノードを示しています。select の場合は 0%、クラスター化インデックスのシークの場合は 100% です。

編集：私が省略したフィールドと値（context_switch_countを除く4つのスレッドすべてで同じ）：exec_context_id(0), host_address(0x00000000), status(0), is_preemptive(0), is_fiber(0), is_sick(0), is_in_cc_exception(0), is_fatal_exception(0), is_inside_catch(0), context_switch_count(3-89078), exception_num(0), exception_Severity(0), exception_address(0x00000000), return_code(0), fiber_address(NULL), language(us_english), date_format(mdy), date_first(7), quoted_identifier(1), ansi_defaults(0), ansi_warnings(1), ansi_padding(1), ansi_nulls(1), concat_null_yields_null(1), executing_managed_code(0)

于 2009-05-27T12:26:37.393 に答える
0

データベースの大きさは? HDD / Raid / その他のストレージの速度はどれくらいですか

おそらくあなたのDBはI / Oバウンドですか？

于 2009-05-21T21:00:21.360 に答える