uWSGI thunder lock contention latency when worker count exceeds CPU cores

Direct Answer

The thunder lock contributes to latency primarily through serialization of accept() calls, with contention becoming measurable when workers exceed CPU cores. The lock_wait metric alone cannot isolate this component from end-to-end request latency percentiles.

Confirmed Facts

• uWSGI uses a system semaphore (Linux) or pthread mutex to serialize accept() calls across workers by default.
• The lock_wait stat exposes aggregate wait time but lacks per-request granularity for percentile correlation.
• Disabling --thunder-lock=false trades serialization for N-process wake-ups, increasing scheduler overhead.
• No documented thresholds exist for when disabling the lock improves vs degrades latency; behavior depends on kernel, connection rate, and worker scheduling.
• Async workers (gevent/eventlet) may experience different contention profiles due to cooperative yielding during accept().

Isolation Methodology

1. Request-level instrumentation: Wrap request handlers with start-to-finish timing (e.g., middleware or uWSGI hookable options) to capture end-to-end latency.
2. Correlated snapshots: Capture lock_wait via stats server every 1-5 seconds during load, aligning with request timing buckets.
3. Controlled comparison: Run identical load tests with --thunder-lock=true vs false at worker counts of 2x, 4x, and 8x CPU cores.
4. Scheduler overhead measurement: Monitor /proc/schedstat or /proc/vmstat to quantify context switches when the lock is disabled.

Practical Steps

To evaluate thunder lock impact in your environment:

--enable-threads
--stats 127.0.0.1:9191
--thunder-lock=true
--workers 8  # adjust to 2-4x your CPU core count

Then run a sustained load test (e.g., wrk -t12 -c400 -d60s) while collecting:

• Request latency percentiles from application logs
• lock_wait snapshots via curl http://127.0.0.1:9191
• Context switches from /proc/<pid>/schedstat

Compare p99 latency and context switch rates between runs with --thunder-lock=false. The metric that changes most is a proxy for lock contention impact.

Worker Type Differences

Sync workers experience direct contention on the semaphore. Gevent/eventlet workers may mask lock contention because the accept() call can yield during the lock wait, but the underlying serialization still occurs at the kernel level. The difference is most visible under high connection rates where wake-up storms affect CPU scheduling.

Verification Requirement

What is your current CPU core count and typical sustained request rate (requests/second)? This determines whether worker counts of 2x-8x cores are appropriate for your load profile and helps refine the worker count recommendations.