You doubled the thread count on each uWSGI worker, expecting throughput to scale with your multi-core box. CPU utilization barely moved. Response time did not improve. Memory looks fine. The queue still fills under load.

The cause is almost certainly the CPython Global Interpreter Lock. In threaded mode, a uWSGI worker runs N OS threads, but all N threads share a single GIL within that process. For CPU-bound Python code, only one thread executes bytecode at a time regardless of how many threads you configured. Adding threads helps with I/O-bound workloads, where threads can yield the GIL while waiting on network or disk, but it does nothing for computation-heavy request handlers.

What it is and why it matters

The GIL is a mutex that protects CPython’s internal data structures from concurrent access. Any thread executing Python bytecode must hold the GIL. Only one thread in a process can hold it at any given moment. The interpreter switches between threads periodically (by default, every 5 milliseconds via sys.setswitchinterval), giving each thread a turn, but execution is effectively serialized for CPU-bound code.

This is not a uWSGI limitation. It is a property of CPython. uWSGI faithfully creates real OS threads when you configure --threads N, and those threads can genuinely handle N concurrent I/O-bound requests. The constraint is that only one of them can run Python computation at a time within a single worker process.

C extensions can release the GIL during long-running operations. NumPy linear algebra, Pillow image processing, and database driver I/O all typically release the GIL. When they do, other threads can execute Python code concurrently. But pure Python computation, including most application business logic, holds the GIL for the duration.

The operational consequence: if your application spends most of its request time in Python code (parsing, serialization, computation, template rendering), adding threads to a worker does not increase CPU parallelism. You need more worker processes, each with its own GIL, to use multiple cores.

How it works

uWSGI’s pre-fork model starts a master process that spawns worker processes. Each worker is a separate OS process with its own memory space and its own GIL. In the default process-based model, concurrency equals the number of workers. Each worker can use a full CPU core for Python computation.

When you enable threaded mode with --threads N, each worker process additionally spawns N OS threads. These threads share the worker’s memory space, including file descriptors, connection pools, and cache. They also share the GIL. The worker can now handle N concurrent requests at the connection level, but for CPU-bound Python work, execution is still serialized within that single process.

There is a related default that catches operators off guard. By default, the uWSGI Python plugin does not initialize the GIL. Application-generated background threads (created via threading.Thread or similar) will not run unless you explicitly set --enable-threads. When you use --threads N, threading support is automatically enabled, so the GIL is initialized. But if you rely on --enable-threads alone to run background threads without spawning additional request-handling threads, you get the GIL initialized without extra request-handling concurrency.

When threading is not enabled, uWSGI replaces the GIL acquire and release functions with no-ops. This eliminates GIL overhead for single-threaded workers but means any thread your application creates will silently stall after the first request completes.

The following diagram contrasts how CPU-bound work is scheduled in threaded versus process-based mode:

flowchart TD
    subgraph Threaded["Threaded mode: 1 worker, 4 threads"]
        T1["Thread 1"] --> GIL["GIL shared by all threads"]
        T2["Thread 2"] --> GIL
        T3["Thread 3"] --> GIL
        T4["Thread 4"] --> GIL
        GIL -->|"one thread at a time"| Out1["1 CPU core for Python computation"]
    end
    subgraph Process["Process mode: 4 workers"]
        W1["Worker 1"] -->|"own GIL"| C1["Core 1: parallel"]
        W2["Worker 2"] -->|"own GIL"| C2["Core 2: parallel"]
        W3["Worker 3"] -->|"own GIL"| C3["Core 3: parallel"]
        W4["Worker 4"] -->|"own GIL"| C4["Core 4: parallel"]
    end

In the threaded case, four threads compete for one GIL. Only one executes Python bytecode at a time, so CPU utilization tops out at one core per worker regardless of thread count. In the process case, each worker has its own GIL and can independently use a CPU core, giving true parallel execution at the cost of N copies of the application in memory.

Where it shows up in production

The classic signature is a deployment change that adds threads and produces no measurable throughput improvement. You will see several symptoms:

  • CPU utilization stays flat. Adding threads from 2 to 8 per worker does not push aggregate CPU past the per-worker ceiling. One core is saturated. The rest are idle.
  • Response time does not improve. It may get slightly worse due to GIL contention overhead and context switching between threads fighting for the lock.
  • Memory looks healthy. Threads share the worker’s memory, so RSS does not grow the way it would with additional processes. This is misleading: memory looks fine because the scaling mechanism (threads) is not the one that provides parallelism.
  • The worker shows “busy” even when most threads are idle. uWSGI reports worker status at the process level. A worker is “busy” if at least one thread is handling a request. A worker with 8 threads and 1 active thread reports the same “busy” status as a worker with all 8 threads active.

This last point is the most operationally significant. The busy ratio, which is your primary capacity utilization metric, loses resolution in threaded mode. You cannot distinguish “one thread stuck, seven idle” from “all eight threads fully occupied” without looking deeper.

The uWSGI stats server exposes per-thread data through the cores[] array within each worker object. Each core corresponds to a thread (in threaded mode). The in_request field on each core tells you whether that thread is currently processing a request:

# Requires the stats server enabled (--stats 127.0.0.1:9191) and jq installed
uwsgi --connect-and-read 127.0.0.1:9191 | jq '[.workers[] | select(.pid > 0) | {worker: .id, active_threads: ([.cores[] | select(.in_request == 1)] | length), total_threads: (.cores | length)}]'

If every worker shows 1 active thread out of 8 configured, you have a GIL bottleneck. If workers show 7 or 8 of 8 active threads, your workload is I/O-bound and the threads are genuinely helping with concurrency.

Note: the cores[] array is suppressed if uWSGI is started with --stats-no-cores. If you see no cores data in your stats output, check whether that flag is set.

You can also add the core:%(core) placeholder to your log-format directive to record which thread handled each request. This gives you thread-level attribution in log analysis, complementing the real-time stats server view.

To confirm the diagnosis at the OS level, check per-thread CPU distribution:

# Show per-thread CPU for all uWSGI worker processes
top -H -p $(pgrep -d, uwsgi)

If one thread per worker is consuming near-100% CPU while the rest sit near-zero, the GIL is your ceiling. The threads exist and are scheduled by the kernel, but they spend most of their time waiting for the lock.

Tradeoffs and when to use it

Threads are appropriate for I/O-bound workloads. If your requests spend most of their time waiting on database queries, external API calls, cache lookups, or file I/O, threads help. While one thread waits on I/O (which releases the GIL), another thread can execute Python code. The worker handles more concurrent connections without needing additional processes.

Processes are necessary for CPU-bound workloads. If your requests do heavy computation in Python (data processing, JSON serialization of large payloads, template rendering), each worker process can only use one CPU core at a time. To use N cores, you need N worker processes.

The memory cost is the tradeoff. Each worker process is a full copy of the application loaded into memory. With copy-on-write, the initial RSS is shared, but pages diverge as workers run and modify state. Four workers cost roughly four times the memory of one worker. Four threads in one worker share one copy. If memory is tight, you may be forced into threaded mode and accept the GIL ceiling for CPU-bound work.

A hybrid approach is common. Multiple worker processes, each with a few threads, balances memory cost against parallelism. For example, on an 8-core machine with a memory budget for 4 processes: 4 processes with 2 threads each gives 8 concurrent request handlers. For CPU-bound Python work, effective parallelism is 4 (the process count). For I/O-bound work, effective concurrency is 8 (the thread count).

Profile your workload first. If your request handler spends 80% of its wall-clock time in database I/O, threads will help significantly. If it spends 80% in Python computation, threads are wasted configuration.

Signals to watch in production

SignalWhy it mattersWarning sign
Per-core in_request countShows how many threads per worker are actually processing requests, not just how many are configuredOnly 1 of N threads active per worker indicates GIL-bound CPU work
Worker busy ratioPrimary capacity utilization metric, but loses resolution in threaded mode100% busy with flat CPU suggests threads are not providing parallelism
Per-worker CPU utilization (OS level)Reveals whether workers are saturating individual coresOne core at 100% per worker while others are idle confirms single-core ceiling
avg_rt (exponential moving average)Tracks response time trend per workerRising avg_rt with flat throughput can indicate GIL contention increasing per-request latency
Total request throughput (delta requests)Shows whether adding threads changed effective processing rateThroughput unchanged after adding threads confirms no parallelism gain
Worker RSSMemory cost comparison between process and thread scalingRSS flat after adding threads (expected for threads); RSS scaling linearly with process count (expected for processes)

The avg_rt signal deserves a caveat. It is computed as (old_avg_rt + current_request_time) / 2, giving roughly 50% weight to the most recent request. A single slow request can shift it significantly. Use it for trend detection, not as a precise latency SLI.

How Netdata helps

  • Per-second CPU metrics per process. Netdata collects per-process and per-core CPU utilization at one-second resolution, letting you see exactly which cores are saturated and whether your worker processes are achieving parallel execution or hitting a single-core ceiling.
  • Correlation between worker status and CPU. Overlay uWSGI worker busy ratio with system CPU utilization. If busy ratio is high but CPU is flat, the GIL is likely the constraint. If both rise together, you have genuine parallelism.
  • Per-core in_request visibility. The uWSGI collector surfaces per-core request data from the stats server, giving you thread-level concurrency visibility without manual jq queries during an incident.
  • avg_rt tracking with anomaly detection. Netdata’s ML-based anomaly detection flags unusual avg_rt shifts, which can surface GIL contention before it becomes a capacity event.
  • Memory trend correlation. Track per-worker RSS alongside process and thread configuration changes to understand the memory cost of your concurrency model over time.