-
Notifications
You must be signed in to change notification settings - Fork 152
Make fog-view load blocks from postgres in batches #2707
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
Conversation
These batches have a size which is configurable as a command line parameter.
// We might have more work to do, we aren't sure because of the error | ||
may_have_more_work = true; | ||
// Let's back off for one interval when there is an error | ||
sleep(DB_POLL_INTERNAL); |
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 am not sure if this is a good idea, but right now I think nothing backs off if we hit the error path, which might be a bad thing.
This is not directly related to the main change.
let proto = ProtoIngestedBlockData::decode(&*proto)?; | ||
result.push(proto.e_tx_out_records); | ||
} else { | ||
log::warn!(self.logger, "When querying for block index {} and up to {} blocks on, the {}'th response has block_number {} which is not expected. Gaps in the data?", block_index, block_count, idx, block_number); |
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.
there is not much reason to think that this code path will happen, but I would rather be defensive
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.
Nice, thank you for the quick turnaround on this.
Some relatively minor suggestions for improvements.
this passed CD |
}; | ||
|
||
// We will get one row for each hit in the table we found | ||
let rows: Vec<(i64, Vec<u8>)> = query.load::<(i64, Vec<u8>)>(&conn)?; |
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.
IIUC we don't need to specify the type twice
let rows: Vec<(i64, Vec<u8>)> = query.load::<(i64, Vec<u8>)>(&conn)?; | |
let rows: Vec<(i64, Vec<u8>)> = query.load(&conn)?; |
let db_test_context = SqlRecoveryDbTestContext::new(logger.clone()); | ||
let db = db_test_context.get_db_instance(); | ||
let db_fetcher = DbFetcher::new(db.clone(), Default::default(), logger); | ||
let db_fetcher = DbFetcher::new(db.clone(), Default::default(), 1, logger); |
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.
It seems useful to exercise a DbFetcher
with batch_size > 1
in this file
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.
yeah, we do that in the smoke test, but I thought it's okay to keep this unit test working with 1
/// Arguments: | ||
/// * ingress_key: The ingress key we need ETxOutRecords from | ||
/// * block_index: The first block we need ETxOutRecords from | ||
/// * block_count: How many subsequent blocks to also request data for. |
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.
Maybe this should be how many consecutive blocks to also request data for? Subsequent seems to suggest 0 should just return only this block_index, and 1 means return this and 1 additional?
/// Arguments: | ||
/// * ingress_key: The ingress key we need ETxOutRecords from | ||
/// * block_index: The first block we need ETxOutRecords from | ||
/// * block_count: How many subsequent blocks to also request data for. |
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.
Similar comment to above.
Co-authored-by: Remoun Metyas <remoun@mobilecoin.com>
* Make fog-view load blocks from postgres in batches These batches have a size which is configurable as a command line parameter. * fixup tests * add unit test for new function * address eran and remoun comments in db_fetcher * change parameter to a usize * rename per request * Update fog/sql_recovery_db/src/lib.rs Co-authored-by: Remoun Metyas <remoun@mobilecoin.com> Co-authored-by: Remoun Metyas <remoun@mobilecoin.com>
* Make fog-view load blocks from postgres in batches (#2707) * Make fog-view load blocks from postgres in batches These batches have a size which is configurable as a command line parameter. * fixup tests * add unit test for new function * address eran and remoun comments in db_fetcher * change parameter to a usize * rename per request * Update fog/sql_recovery_db/src/lib.rs Co-authored-by: Remoun Metyas <remoun@mobilecoin.com> Co-authored-by: Remoun Metyas <remoun@mobilecoin.com> * Nits from fog view db fetch pr (#2714) * fix nits from fog-view-db-fetch pull request * update changelog Co-authored-by: Remoun Metyas <remoun@mobilecoin.com>
These batches have a size which is configurable as a command line parameter.
The point of this is that we have been having issues where the network latency to get from fog-view to postgres has been high enough that it becomes the bottleneck for fog-view loading all the data into ORAM, and begins to significantly negatively impact the time to restart fog view. We can make the server more tolerant of that by making it try to load more data at once.
Thanks to James for suggested approach here