Course contentsShow
← Linux
Lesson 1652 of 1,81914. Observability and Performance TroubleshootingFree lesson

Identifying Thundering Herd Problems

Diagnose application race conditions during synchronization events through kernel event monitoring.

Identifying Thundering Herd Problems

In this lesson, you will learn how to diagnose "thundering herd" synchronization issues by observing kernel-level wake-up events that trigger massive, redundant context switching.

A thundering herd occurs when multiple threads are blocked on a single synchronization primitive—like a wait_queue for a mutex or a condition variable—and the kernel wakes all of them simultaneously when the event occurs. Even though all threads wake up, only one can acquire the resource; the rest immediately contend, fail, and go back to sleep. This creates a massive spike in CPU utilization and latency, often masking the actual application logic.

Observing the Herd with BPF

To identify this, you must monitor the transition from a blocked state to a running state across many processes for the same synchronization object. We can use eBPF to hook into try_to_wake_up and trace the number of tasks awakened for a specific wait queue address.

If you observe an imbalance where a single event (like epoll_wait or a mutex unlock) triggers a cascade of wake-ups, you have confirmed a thundering herd.

SEC("kprobe/try_to_wake_up")
int BPF_KPROBE(trace_wakeup, struct task_struct *p) {
    // Check if the task is being moved to a running state
    // Trace the target wait_queue address associated with the task
    u64 queue_addr = (u64)p->pi_top_waiter; 
    
    // Aggregate wake-up counts by the synchronization primitive address
    u64 *count = bpf_map_lookup_or_try_init(&wakeup_counts, &queue_addr);
    if (count) {
        __sync_fetch_and_add(count, 1);
    }
    return 0;
}

By correlating these wake-up spikes with your application's futex or epoll call frequency, you can pinpoint whether your synchronization logic is causing unnecessary context-switch overhead. If a single event causes the wakeup_counts for a specific address to spike significantly higher than one, your application is suffering from thundering herd behavior.

Key Takeaway: A thundering herd is identified by monitoring excessive wake-up signals for a single synchronization point, which reveals inefficient resource contention that cascades into system-wide performance degradation.