SQL Server LCK_M waits high: lock contention and what the suffixes mean

When LCK_M_* wait types dominate sys.dm_os_wait_stats, worker threads are suspended waiting for locks instead of doing work. The prefix is uniform; the suffix is the lock mode the waiter requested, and it is the diagnostic signal. LCK_M_S means a reader is blocked. LCK_M_IX means an intent-exclusive writer is queued behind a conflicting holder. LCK_M_SCH_M is a DDL operation waiting on schema modification. The mode narrows the suspect list immediately.

High LCK_M wait time is blocking measured from the wait side. The cumulative number in sys.dm_os_wait_stats is interesting, but the live blocking chain in sys.dm_exec_requests and sys.dm_os_waiting_tasks tells you whether you are looking at one bad session or a structural problem. Zero deadlocks during a high-LCK_M event does not mean the system is healthy: near-miss contention can deadlock under additional load.

What this means

The LCK_M family is the lock manager exposing its wait queue. SQL Server uses hierarchical locking (row, page, table, database), so most workloads take fine-grained locks. When a request cannot acquire the mode it needs at the level it needs, the worker thread is suspended and records an LCK_M_<mode> wait.

Reading the suffix

SuffixLock mode requestedTypical waiter
LCK_M_SSharedSELECT under READ COMMITTED needing to read the resource
LCK_M_UUpdateUPDATE search phase before X conversion; SELECT with UPDLOCK hint
LCK_M_XExclusiveINSERT/UPDATE/DELETE on the locked resource
LCK_M_ISIntent SharedReader wanting to take an S lock at a finer granularity
LCK_M_IUIntent UpdateSession escalating intent chain toward U
LCK_M_IXIntent ExclusiveWriter wanting to take an X lock at a finer granularity
LCK_M_SCH_SSchema StabilityAny query briefly taking Sch-S before plan execution
LCK_M_SCH_MSchema ModificationDDL: index rebuild, ALTER TABLE, partition switch
LCK_M_SIU / LCK_M_SIX / LCK_M_UIXCombined intent modesLess common; specific access paths

SQL Server 2014 added _ABORT_BLOCKERS and _LOW_PRIORITY variants for every base type. They appear only when WAIT_AT_LOW_PRIORITY is used with online index operations or ALTER TABLE. Seeing them in a wait report almost always points back to a maintenance job that could not acquire its lock cleanly.

Why the suffix changes the fix

LCK_M_S contention is readers blocked by an uncommitted writer. The fix is RCSI or committing the writer. LCK_M_SCH_M contention is a maintenance job blocked by a single long-running SELECT; the fix is WAIT_AT_LOW_PRIORITY or rescheduling. LCK_M_IX mixed with LCK_M_S after a big batch update is classic lock escalation: one transaction is holding a table-level X lock. The suffix is a one-word clue to which playbook applies.

Common causes

CauseWhat it looks likeFirst thing to check
Uncommitted transaction from app bugHead blocker is sleeping with no active request; blocked sessions wait on LCK_M_S or LCK_M_Xsys.dm_exec_requests for blocking_session_id, then sys.dm_exec_sessions.status of the blocker
Lock escalationOne update blocked many writers; LCK_M_IX and LCK_M_S both high after batch writeExtended Events lock_escalation; row count of the batch vs the ~5000 lock threshold
DDL during business hoursLCK_M_SCH_M dominant; blocked sessions wait on LCK_M_SCH_S or LCK_M_ISsys.dm_tran_locks for LCK_M_SCH_M holders
Long-running SELECT blocking writerWriter waits on LCK_M_X; reader holds S on the same keysys.dm_os_waiting_tasks + resource_description to find the key
Hot row (sequence, last-page insert)Many sessions wait on the same resource_description repeatedlyRepetition of resource_description across blocked sessions

Quick checks

-- Cumulative LCK_M waits by mode since startup or last reset
SELECT
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS avg_wait_ms,
    (wait_time_ms - signal_wait_time_ms) AS resource_wait_ms
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'LCK_M_%'
ORDER BY wait_time_ms DESC;

-- Live blocking chains: who is blocked, by whom, on what wait type
SELECT
    r.session_id AS blocked_session,
    r.blocking_session_id AS blocker,
    r.wait_type,
    r.wait_time / 1000 AS wait_seconds,
    DB_NAME(r.database_id) AS database_name,
    t.text AS blocked_query_text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0
ORDER BY r.wait_time DESC;

-- Specific locked resource for each waiter
SELECT
    wt.session_id,
    wt.wait_type,
    wt.wait_duration_ms,
    wt.blocking_session_id,
    wt.resource_description
FROM sys.dm_os_waiting_tasks wt
WHERE wt.wait_type LIKE 'LCK_M_%'
ORDER BY wt.wait_duration_ms DESC;

-- Head blockers that are sleeping (no active request): the dangerous ones
SELECT
    s.session_id,
    s.login_name,
    s.host_name,
    s.program_name,
    s.last_request_start_time,
    s.status,
    s.open_transaction_count,
    (SELECT COUNT(*) FROM sys.dm_exec_requests r2
     WHERE r2.blocking_session_id = s.session_id) AS sessions_blocked
FROM sys.dm_exec_sessions s
WHERE s.session_id IN (
    SELECT DISTINCT blocking_session_id FROM sys.dm_exec_requests
    WHERE blocking_session_id <> 0
)
AND s.session_id NOT IN (
    SELECT session_id FROM sys.dm_exec_requests WHERE blocking_session_id <> 0
)
ORDER BY sessions_blocked DESC;

All four queries are read-only. The third query (sys.dm_os_waiting_tasks) turns LCK_M_S from a number into a concrete locked key.

How to diagnose it

  1. Snapshot cumulative waits. Run the first quick check twice, 30-60 seconds apart, and compute deltas. sys.dm_os_wait_stats is cumulative since startup; a single read means nothing.

  2. Identify the dominant suffix. Of the delta, which LCK_M_* mode consumed the most wait_time_ms? That mode tells you which side of the conflict to investigate: reader, writer, or DDL.

  3. Find the live blocking chain. Run the second quick check. If rows are present, you have an active problem. If the chain is empty but wait stats keep climbing, your sample window missed the event. Use the blocked_process_report Extended Event for short-lived blocking.

  4. Decode the resource. Cross-reference sys.dm_os_waiting_tasks.resource_description for at least one blocked session. The format tells you what is locked: keylock for a row key, ridlock for a heap row, pagelock for a page, objectlock or hobtlock for table or partition. The same resource_description repeating across many waiters is a hot row.

  5. Identify the head blocker. Run the fourth quick check. A head blocker that is sleeping with open_transaction_count > 0 and no active request is an uncommitted transaction from a connection returned to the pool. It will not resolve itself.

  6. Correlate with worker thread usage. Blocking chains consume workers. If you are near max_workers_count or seeing THREADPOOL waits, this is no longer a tuning problem; it is an outage that needs the head blocker killed now.

flowchart TD
    A[LCK_M waits high in dm_os_wait_stats] --> B{Active blocking in dm_exec_requests?}
    B -- No --> C[Shorter window or XEvents capture]
    B -- Yes --> D[Decode suffix: S, X, SCH_M, IX]
    D --> E[Find head blocker via dm_os_waiting_tasks]
    E --> F{Head blocker sleeping?}
    F -- Yes --> G[Uncommitted transaction - KILL after assessment]
    F -- No --> H[Lock level: key vs object vs HOBT]
    H --> I{Object/HOBT lock from one session?}
    I -- Yes --> J[Lock escalation - shorter batches, indexing]
    I -- No --> K[Reader/writer or DDL - RCSI, scheduling]
    G --> L[Watch worker thread pool]
    J --> L
    K --> L

Metrics and signals to monitor

SignalWhy it mattersWarning sign
LCK_M_* delta wait_time_ms per 30-60sShows current contention, not lifetime averageAny single mode climbing while batch requests drop
Blocking chain depth (sys.dm_exec_requests)A single head blocker can drain the worker poolChain deeper than 5 sessions or oldest wait above 60s
Head blocker statussleeping means it will not self-resolveSleeping head blocker with open transaction
Worker thread utilizationBlocking consumes workers; cascade riskTHREADPOOL waits or active workers above 80% of max
Deadlocks/secNear-miss contention becomes real deadlocksAny rise from a zero baseline during the LCK_M event
Batch Requests/sec flat or dropping while connections riseWork arriving but not completingThroughput collapse without CPU or I/O pressure
lock_escalation Extended EventsOne transaction traded many row locks for a table lockEscalation on a table other writers need

Fixes

Uncommitted transaction from application bug

The shortest path is: identify the head blocker, verify it is sleeping with open_transaction_count > 0 (query four, or DBCC OPENTRAN in the blocker’s database), then KILL <session_id>.

Warning: KILL rolls back the open transaction. Rollback can take as long as the original work, and the session’s locks remain held until rollback completes. Assess the blast radius before killing a session blocking dozens of workers.

The real fix is in the application: explicit transactions must always commit or rollback in a finally block, and connection pool return paths must not allow a transaction to leak.

Lock escalation

When a single transaction holds more than roughly 5000 row or page locks on one table, the lock manager escalates to a single table lock. If the workload legitimately needs large batch updates, options are: smaller batches (the most reliable fix), a covering index so the update touches only the rows it needs, or explicit TABLOCK hints when the writer really does want the whole table and other writers can wait. Disabling lock escalation (ALTER TABLE ... SET (LOCK_ESCALATION = DISABLE)) is rarely the right answer; it shifts the problem to lock memory pressure.

Schema modification waits (LCK_M_SCH_M)

Sch-M is incompatible with everything, including the brief Sch-S lock that every SELECT takes. The classic pattern is an offline index rebuild blocked by one long SELECT, which then blocks every subsequent SELECT, producing a cascade of LCK_M_IS waits behind the original LCK_M_SCH_M. Fixes, in order of preference: schedule DDL outside business hours, use online index operations with WAIT_AT_LOW_PRIORITY (Enterprise Edition), or use ABORT_AFTER_WAIT = SELF so the maintenance job is the victim rather than the workload.

Reader/writer blocking under READ COMMITTED

The default READ COMMITTED isolation level takes shared locks for the duration of the read. Writers waiting on LCK_M_X while many readers hold S locks is the canonical case for Read Committed Snapshot Isolation (RCSI). Enabling RCSI eliminates reader-writer blocking because readers use row versions from the version store instead of S locks. The tradeoff is TempDB usage for the version store, so monitor TempDB space and version-store growth after enabling it.

Hot row

If resource_description repeats across many waiters, you have a single hot row: last-page insert on a monotonically increasing key, an application-level sequence table, or a “next available” counter. Fixes are structural: hash partitioning on the hot index, sequence objects instead of a counter table, or application-level batching. None of them are quick.

Prevention

  • Trend LCK_M waits as deltas, not cumulative values. A weekly spike in LCK_M_S resource wait time, even with no deadlocks, is a leading indicator of an upcoming cascade.
  • Enable the blocked process report. Set sp_configure 'blocked process threshold' to a small value (5-15 seconds) and capture the blocked_process_report Extended Event. Short blocking that never pages anyone still shows up here.
  • Snapshot blocking chains at 30-second intervals. Transient blocking is invisible to a human watching sp_who2; a periodic collector catches the head blocker before it disappears.
  • Review lock_escalation events as a time series. Repeated escalation on the same table is a structural signal that the workload has outgrown its indexing or batch strategy.
  • Default to RCSI for new OLTP databases. The TempDB cost is well understood and almost always smaller than the cost of reader-writer blocking at peak.

How Netdata helps

The SQL Server integration collects sys.dm_os_wait_stats on a per-second cadence and breaks LCK_M waits down by mode, so the suffix pattern (LCK_M_S vs LCK_M_SCH_M vs LCK_M_IX) is visible as a time series rather than a single cumulative number. Blocking chain depth and head blocker session ID are correlated against wait type, so a sudden LCK_M_X rise can be matched to the session that started the cascade at the same second. Worker thread utilization is tracked alongside waits, which is the single most important correlation when deciding whether the LCK_M event is a tuning issue or an imminent THREADPOOL outage.

Batch Requests/sec, transactions/sec, and User Connections are visualized together, making the “work arriving but not completing” pattern visible. Deadlock count is tracked next to LCK_M wait time, so a high-LCK_M event with zero deadlocks shows up as a near-miss rather than being dismissed.

For details, see Microsoft SQL Server monitoring with Netdata.