-
Notifications
You must be signed in to change notification settings - Fork 229
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
Report vstorage size delta for set() operations via telemetry #10997
Conversation
golang/cosmos/x/vstorage/vstorage.go
Outdated
@@ -101,6 +147,7 @@ func (sh vstorageHandler) Receive(cctx context.Context, str string) (ret string, | |||
if err != nil { | |||
return | |||
} | |||
reportKVEntrySizeDelta(ctx, keeper, entry, msg.Method) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to add a similar call to reportKVEntrySizeDelta() in case "append":
below?
if yes, what should it be reporting as it is not clear to me how exactly "append" works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely need this for "append". The implementation is in vstorage/keeper/keeper.go, and the summary is that inbound data extends rather than replaces preëxisting data except at block boundaries (for which the old data is permanently committed into history and can be recovered by querying for the previous block). And as @mhofman suggests, we really want the delta calulation at that point anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to do the calculation of size delta closer to the DB access. Instrumenting at Receive
causes us to perform extra DB operations which are expensive. It also cannot properly account for the "update" an existing entry case, especially in the "append" mode. The keeper already needs to read the DB, so it should be a much better place to do the accounting.
916a907
to
81840a4
Compare
Deploying agoric-sdk with
|
Latest commit: |
a8e9c91
|
Status: | ✅ Deploy successful! |
Preview URL: | https://d4edc90a.agoric-sdk.pages.dev |
Branch Preview URL: | https://sliakh-10938-vstorage-write.agoric-sdk.pages.dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The overall modifications seem good to me, but looking at the telemetry
package source code, we should anticipate a future in which we account for all chain storage and label metrics by storeKey. I've added corresponding suggestions.
Testing coverage would be nice, but those gaps are neither new nor exacerbated by this work. But can you document the process and results of manual testing in this PR?
Co-authored-by: Richard Gibson <[email protected]>
Deploying agoric-sdk with
|
Latest commit: |
36bdd97
|
Status: | ✅ Deploy successful! |
Preview URL: | https://73068153.agoric-sdk.pages.dev |
Branch Preview URL: | https://sliakh-10938-vstorage-write.agoric-sdk.pages.dev |
Deploying agoric-sdk with
|
Latest commit: |
1596289
|
Status: | ✅ Deploy successful! |
Preview URL: | https://f262b963.agoric-sdk.pages.dev |
Branch Preview URL: | https://sliakh-10938-vstorage-write.agoric-sdk.pages.dev |
Deploying agoric-sdk with
|
Latest commit: |
b5e1d42
|
Status: | ✅ Deploy successful! |
Preview URL: | https://fcd11148.agoric-sdk.pages.dev |
Branch Preview URL: | https://sliakh-10938-vstorage-write.agoric-sdk.pages.dev |
@siarhei-agoric where did we land on this? |
Sorry, missed that first time around. Updated the "Testing Considerations" section in OP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing this at the level of the keeper is so much cleaner, thanks for this!
It looks like cosmos-sdk always reports these telemetry in a defer
, I'm wondering why.
Removed automerge label to let you address question. Feel free to reapply if no changes needed. |
My guess is to ensure that errors from attempting to update telemetry don't interfere with the business logic, although that seems of dubious value to me. |
refs: #10938
Description
add
vstorage_size_delta
metric to vstorage keeper. The metric is reported for eachSet()
andDelete()
storage operation.Security Considerations
none
Scaling Considerations
This change adds an explicit
Get()
call for eachSet()
/Delete()
operationDocumentation Considerations
cosmos telemetry will emit a new metric
vstorage_size_delta
Testing Considerations
Manual testing.
First terminal:
Second terminal:
Output after a long startup delay:
Upgrade Considerations
none