You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we receive one of the core a block, attestation, exit messages there's a chance that we might need to access a historical state. Accessing these states can take seconds to load, even 10s of seconds if the system/db is under load.
AIUI, we are not using Tokio's blocking threadpool to process these messages, instead they're just blocking the main pool. This will cause network messages, API calls, etc. to be delayed.
I've seen some attestation processing scenarios take 30 seconds! If we were to process two of these messages on a dual-core CPU, then we'd stop responding to messages for 30s. This would potentially cause us to loose peers and perhaps stop following head.
Steps to resolve
Ensure all non-trivial consensus message processing tasks are spawned on the blocking executor.
The text was updated successfully, but these errors were encountered:
Description
When we receive one of the core a block, attestation, exit messages there's a chance that we might need to access a historical state. Accessing these states can take seconds to load, even 10s of seconds if the system/db is under load.
AIUI, we are not using Tokio's blocking threadpool to process these messages, instead they're just blocking the main pool. This will cause network messages, API calls, etc. to be delayed.
I've seen some attestation processing scenarios take 30 seconds! If we were to process two of these messages on a dual-core CPU, then we'd stop responding to messages for 30s. This would potentially cause us to loose peers and perhaps stop following head.
Steps to resolve
Ensure all non-trivial consensus message processing tasks are spawned on the blocking executor.
The text was updated successfully, but these errors were encountered: