Связанные с производительностью: как SQL Server обрабатывает одновременные запросы от нескольких подключений из одного настольного приложения .NET?

Это просто выстрел в темноту, но я уверен, что вы не видите прироста производительности, потому что они сериализуются в базе данных из-за блокировки общих ресурсов (записей). Теперь о мелком шрифте.

Я предполагаю, что ваш код С# действительно правильный, и вы действительно запускаете отдельные потоки и выполняете каждый запрос параллельно. Без обид, но я видел, как многие заявляют об этом, и код на самом деле является последовательным в клиенте по разным причинам. Вы должны проверить это, наблюдая за сервером (через Profiler или используя sys.dm_exec_requests и sys.dm_exec_sessions).

Также я предполагаю, что ваши запросы имеют аналогичный вес. т. е. у вас нет одного потока, который длится 15 секунд, и 5, которые 100 мс.

Симптомы, которые вы описываете, при отсутствии более подробной информации указывают на то, что у вас есть операция записи в начале каждого потока, который блокирует X на каком-либо ресурсе. Первый поток запускается и блокирует ресурс, остальные 5 ждут. 1-й поток выполнен, освобождает ресурс, затем его захватывает следующий, остальные 4 ждут. Таким образом, последний поток должен ждать выполнения всех остальных 5. Это было бы чрезвычайно легко устранить, посмотрев sys.dm_exec_requests и отслеживайте, что блокирует запросы.

Кстати, вам следует рассмотреть возможность использования асинхронной обработки = true и полагаться на асинхронные методы, такие как BeginExecuteReader, для запуска ваших команд в параллельном выполнении без накладных расходов на потоки на стороне клиента.

Вы можете просто проверить диспетчер задач, когда процесс запущен. Если он показывает загрузку ЦП на 100%, значит, он привязан к ЦП. В противном случае его IO Bound.

Для гиперпоточности 50% использования ЦП примерно равно 100% использованию!

Вау, я и не знал, сколько лет теме. Я думаю, что всегда хорошо оставить ответ для других.

Насколько велика ваша база данных? Насколько быстры ваши жесткие диски / RAID / Другое хранилище

Возможно, ваша БД связана с вводом-выводом?

Моя первая мысль заключается в том, что вы пытаетесь решить проблему ввода-вывода с помощью потоков, что почти никогда не работает. IO есть IO, и большее количество потоков не увеличивает конвейер. Вам лучше загружать все вопросы и ответы на них одним пакетом и обрабатывать пакет локально с помощью нескольких потоков.

Сказав это, вы, вероятно, испытываете некоторую блокировку базы данных, которая вызывает медлительность. Поскольку вы говорите о запросах только для чтения, попробуйте использовать подсказку with (nolock) в своих запросах, чтобы увидеть, поможет ли это.

Что касается обработки SQL-сервера, насколько я понимаю, SQL Server будет пытаться обрабатывать как можно больше подключений одновременно (по одному оператору за раз для каждого подключения), вплоть до максимального количества подключений, разрешенного конфигурацией. Проблема if, которую вы видите, почти никогда не связана с проблемой потока и почти всегда связана с блокировкой или проблемой ввода-вывода.

Возможно ли, что потоки имеют общее соединение? Вы проверили, что при запуске создается несколько SPID (sp_who)?

Я выполнил запрос соединения между sys.dm_os_workers, sys.dm_os_tasks и sys.dm_exec_requests по адресу task_address, и вот результаты (некоторые неинтересные поля с нулевым значением исключены, другие снабжены префиксом 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

Предсказатель плана запроса для всех запросов показывает пару узлов, 0% для выбора и 100% для поиска по кластеризованному индексу.

Изменить: поля и значения, которые я пропустил, где (одинаковые для всех 4 потоков, кроме context_switch_count): 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)