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

Range-lock wait types (LCK_M_RS_S, LCK_M_RS_U, and the LCK_M_RX_* family) are documented wait types in sys.dm_os_wait_stats; they appear under SERIALIZABLE isolation or other range-locking scenarios.

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.

Optimized locking is enabled by default in Azure SQL Database and in Azure SQL Managed Instance (with the SQL Server 2025 update policy). On-premises it is a SQL Server 2025 feature, disabled by default. When it is enabled, additional wait types such as LCK_M_S_XACT and LCK_M_S_XACT_READ appear in wait statistics.

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

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

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.

On instances with the common criteria compliance enabled server option turned on, every login performs additional Residual Information Protection work, which Microsoft documents as a performance cost under heavy login/logout churn and which has been reported as LCK_M_SCH_M spikes during login storms.

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.

Related guides

• SQL Server buffer cache hit ratio low: when the working set no longer fits in memory
• SQL Server user connections climbing: connection pool leaks and retry storms
• SQL Server CPU utilization high: telling query load apart from a bad plan
• SQL Server CXPACKET and CXCONSUMER waits: parallelism, MAXDOP, and what is actually wrong
• SQL Server Error 701: there is insufficient system memory to run this query
• SQL Server Error 9002: the transaction log for the database is full
• SQL Server high compilations per second: plan cache pollution and CPU burn
• How Microsoft SQL Server actually works in production: a mental model for operators
• SQL Server log autogrow stall: why every write pauses while the log file grows
• SQL Server log backups missing: the full-recovery log that grows forever
• SQL Server log_reuse_wait_desc: why the transaction log will not truncate
• SQL Server transaction log percent used climbing toward full