Aglet

Triage worker concurrency thrashing with resource traces

Concurrency thrashing is a relationship between parallelism and useful work, not a high resource reading by itself. Triage the same workload at two or more controlled concurrency levels. Capture completion, queue delay, errors, and the shared resources that may make additional workers compete rather than progress.

Establish what is happening

  1. Hold the workload constant

    Choose a sanitized job mix with fixed record count, payload shape, and downstream dependencies. Run it at a lower and higher concurrency while recording ready, claim, start, and terminal times. Keep worker image and database state comparable so the comparison has one main variable.

  2. Trace shared resource pressure

    Capture CPU, memory, database connections, lock waits, I/O, and error or retry events for each run. Mark when saturation begins and whether queue age grows at the same point. A resource peak without slower completion is evidence to retain, not proof of thrashing.

  3. Separate throughput from claim delay

    Compare useful completed work per interval with time waiting to claim and time executing. Inspect whether more workers displace one another, increase retries, or merely expose a downstream limit. Preserve the exact concurrency setting at the first divergence.

What to carry forward

Return matched workload settings, resource traces, claim and execution intervals, completion outcomes, and the first concurrency divergence. Classify the scope as shared-resource contention, retry amplification, queue delay, or no confirmed thrash. Keep causation provisional until a bounded comparison supports it.

Technical background: Rails guides.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow