リソース待機SQLCLR-SPID 0によるwait_type CLR_SEMAPHORE
更新
アーロンの投稿の下のコメントには、なぜこれを見つけたいのかについての広範な説明があります。知りたい場合は、それを読んでください。
システムは、一部のETL、レポートサービス、およびレプリケーションサブスクリプションを実行しています。 SQLエンジンは2012です。再起動後、5分以内に開始し、決して消えることはありません。ユーザーが接続されておらず、SSISが実行されておらず、レポートが提供されておらず、レプリケーションが中断されている場合でも、これは発生します。
これの一番下に到達しようとしている理由は、1つのシステムでのみ、毎分20秒の無意味な待機ティックがあり、サーバーインスタンス自体と私のssmsウィンドウ以外には何も実行されていないためです。同時に、重いCLR操作（たとえば、大規模なデータセットにいくつかのカスタムclrを適用する）を処理しようとすると、処理時間が最大20秒から最大20分に増加しました。
これらのカスタムアセンブリはすべてアンロードされ、サーバーが再起動されましたが、待機が続いています。
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
------------------------------------------------------------ -------------------- -------------------- -------------------- --------------------
CLR_AUTO_EVENT 21178 269767282 1817841 1117
CLR_SEMAPHORE 4704 83518913 20051 180
CLR_MANUAL_EVENT 58 377 109 0
CLR_TASK_START 2376 376 13 136
上記の数値は、ssis/ssrsとアドホッククエリの使用を最小限に抑えてサーバーを最大24時間実行した場合のものです。
/更新
数週間以来、私はこの特定のワットの状況の待ち時間を増やし続けています：
name wait_info
timestamp 38:57.3
wait_type CLR_SEMAPHORE
opcode Begin
duration 0
signal_duration 0
callstack NULL
collect_current_thread_id 1888
event_sequence 249
last_error 0
client_connection_id 00000000-0000-0000-0000-000000000000
client_pid 0
is_system FALSE
nt_username
query_hash 0
session_id 0
session_nt_username
transaction_id 0
request_id 0
query_plan_hash 0
scheduler_id 2
約50秒ごとに起動し、20秒待機してからドロップします。これが示す唯一の場所は、アクティビティモニターの「待機中のタスク」とグループ化された「リソース待機」内ですが、それを超える詳細を見つけるのは難しいことが判明しました。結局、私はこの拡張イベントを作成し、小さなバガーを捕まえましたが、これがどこから来てどのように修正するのかまだ手掛かりがありません。いくつかのドキュメントを私に示すことができる人は大歓迎です。
create EVENT SESSION [InvestigateWaits] on server add EVENT sqlos.wait_info (
ACTION(package0.collect_current_thread_id
, package0.event_sequence
, package0.last_error
, package0.process_id
, sqlos.scheduler_address
, sqlos.scheduler_id
, sqlos.system_thread_id
, sqlserver.client_app_name
, sqlserver.client_connection_id
, sqlserver.client_hostname
, sqlserver.client_pid
, sqlserver.context_info
, sqlserver.database_name
, sqlserver.is_system
, sqlserver.nt_username
, sqlserver.plan_handle
, sqlserver.query_hash
, sqlserver.query_plan_hash
, sqlserver.request_id
, sqlserver.session_id
, sqlserver.session_nt_username
, sqlserver.session_resource_group_id
, sqlserver.session_resource_pool_id
, sqlserver.session_server_principal_name
, sqlserver.sql_text
, sqlserver.transaction_id
, sqlserver.transaction_sequence
, sqlserver.tsql_frame
, sqlserver.tsql_stack
, sqlserver.username)
where ([package0].[equal_uint64]([wait_type], (223)))) add TARGET package0.ring_buffer
with (
MAX_MEMORY = 51200 KB
, EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS
, MAX_DISPATCH_LATENCY = 5 SECONDS
, MAX_EVENT_SIZE = 0 KB
, MEMORY_PARTITION_MODE = NONE
, TRACK_CAUSALITY = off
, STARTUP_STATE = off
)
go
CLR_SEMAPHOREのようなタイマー/キューの待機について心配する必要はありません。これらの待機は常に待機時間を累積しますが、これはすべてのケースの99.999％で「悪い」待機時間ではありません。あなたはそれらを分析から除外し、重要なものに焦点を当て、そしてとにかく何でもできることをすべきです。 Paul RandalのNOT INリストをガイドとして使用します。