Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate runtime estimator panic after PR#3505 #3598

Closed
ailisp opened this issue Nov 12, 2020 · 1 comment
Closed

Investigate runtime estimator panic after PR#3505 #3598

ailisp opened this issue Nov 12, 2020 · 1 comment
Assignees
Labels
A-transaction-runtime Area: transaction runtime (transaction and receipts processing, state transition, etc)

Comments

@ailisp
Copy link
Member

ailisp commented Nov 12, 2020

No description provided.

@ailisp ailisp added the A-transaction-runtime Area: transaction runtime (transaction and receipts processing, state transition, etc) label Nov 12, 2020
@ailisp ailisp self-assigned this Nov 12, 2020
@ailisp
Copy link
Member Author

ailisp commented Nov 13, 2020

The panic is due to randomness selecting account when add some key value to storage, and in next step metric doesn't have required keys in storage because randomly select other accounts which did not have add key value step. Therefore some metric (trigger when delete key value in storage) didn't trigger at all, and cause either stat calc overflow, or some key doesn't present in metric stat at all and panicked (not every time panicked, and may panicked for one of these two places). @evgenykuzyakov observed it didn't happen when there's a warmup iter, but i think that's warmup iter increase total number of txns and has a higher chance that one time account has key value to delete and thus the delete from store metrics is recorded. And obviously this is not correct as most of time delete from store metrics is not triggered.

So back to PR, #3505 itself has no issue, above described is a long existing issue in runtime params estimator and described in issue #3601

@ailisp ailisp closed this as completed Nov 13, 2020
near-bulldozer bot pushed a commit that referenced this issue Dec 8, 2020
Fix #3601. get new numbers which is very different from existing genesis.json, but reasonable compare to run runtime-param-estimator from master branch

Test Plan
------------
runtime-param-estimator works, no #3598 and #3601. And every delete storage actually delete, not noop.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-transaction-runtime Area: transaction runtime (transaction and receipts processing, state transition, etc)
Projects
None yet
Development

No branches or pull requests

1 participant