Separate async and blocking task counters in beacon processor

[jimmygchen]

The beacon processor counts async and blocking tasks in the same bucket, which can cause the node to struggle when there are long-running async tasks. This prevents the processor from scheduling more work even when CPU capacity is available.

Problem

• The beacon processor uses a single current_workers counter for both async and blocking tasks
• Worker capacity checks compare current_workers against max_workers (set to CPU count)
• Async tasks like BlocksByRangeRequest don't block threads but still consume a worker slot
• Long-running async tasks can take seconds while holding a slot
• This prevents CPU-intensive blocking tasks from being scheduled, even when the CPU is idle

Proposed Changes

The current approach treats all work the same, but async and blocking tasks have different resource usage patterns. Possible solutions:

• Manage async and blocking tasks with separate counters and capacity limits within the beacon processor
• Alternatively, let the tokio runtime manage async tasks directly while the beacon processor only manages blocking work
• Consider that blocking tasks may use rayon thread pools, so capacity planning should avoid over-scheduling

The safest approach is likely to start with separate management within the beacon processor before considering delegation to tokio.

Testing

• Monitor beacon processor metrics during various load scenarios (sync, high RPC load, attestation bursts, sync committee messages)
• Verify that CPU utilization stays high without over-subscription
• Test that blocking tasks get scheduled promptly during heavy async activity

[nadtech-hub]

may I take on it?

[eserilev]

I have a POC here:
eserilev#23