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
Investigating state-sync performance on devnet, we noticed that the amount of I/O while a state-sync snapshot is being created can cause a node to fall behind. This is apparently because the commits of the cosmos DB take much longer when a significant amount of changes occurred during the block. This behavior does not happen when the fast node mode is disabled.
We do not actually read / iterate much from the DB, except during state-sync export, which is impacted negatively by fast mode, so there is no reason to have it on.
The DefaultConfig() has IAVLDisableFastNode: false
Description of the Design
In #9424 we fixed the ability to control this mode by config.
Here we would either wwitch IAVLDisableFastNode: true in DefaultConfig() or find a better way to override defaults in agoric-sdk without patching cosmos-sdk. Unfortunately the only "blessed" path appears to be passing a different config to InterceptConfigsPreRunHandler in the root cmd, but from what we understand, this only affects the generation of the config file the first time around, not the actual default if nothing is specified in the config file.
Security Considerations
None
Scaling Considerations
Supposedly this config makes sequential iteration more efficient but we have yet to observe that. So far it has only caused performance issues.
Test Plan
TBD
Upgrade Considerations
Disabling the flag on a DB where the flag was previously enabled seems safe and effective. Reenabling it would likely cause the index to be re-created, which is expensive.
The text was updated successfully, but these errors were encountered:
What is the Problem Being Solved?
Investigating state-sync performance on devnet, we noticed that the amount of I/O while a state-sync snapshot is being created can cause a node to fall behind. This is apparently because the commits of the cosmos DB take much longer when a significant amount of changes occurred during the block. This behavior does not happen when the fast node mode is disabled.
We do not actually read / iterate much from the DB, except during state-sync export, which is impacted negatively by fast mode, so there is no reason to have it on.
The
DefaultConfig()
hasIAVLDisableFastNode: false
Description of the Design
In #9424 we fixed the ability to control this mode by config.
Here we would either wwitch
IAVLDisableFastNode: true
inDefaultConfig()
or find a better way to override defaults in agoric-sdk without patching cosmos-sdk. Unfortunately the only "blessed" path appears to be passing a different config toInterceptConfigsPreRunHandler
in the root cmd, but from what we understand, this only affects the generation of the config file the first time around, not the actual default if nothing is specified in the config file.Security Considerations
None
Scaling Considerations
Supposedly this config makes sequential iteration more efficient but we have yet to observe that. So far it has only caused performance issues.
Test Plan
TBD
Upgrade Considerations
Disabling the flag on a DB where the flag was previously enabled seems safe and effective. Reenabling it would likely cause the index to be re-created, which is expensive.
The text was updated successfully, but these errors were encountered: