-
Notifications
You must be signed in to change notification settings - Fork 637
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
fix(runtime-params-estimator): disable rocksdb thread in it #3091
Conversation
Seems parameter estimator get stuck in the middle after turn off all threads, probably due to there's limit of how big the state it can have. will see if i can increase the bar to proceed. Update: have some little clue with debug print and lldb, it is not blocking by rocksdb writing limits (have increased all of them to unlimited or very high). Looking at debug print, measure_actions never returns. Looking at lldb after it stucks, rockdb wait for a ConditionVar in the rocksdb destructor (but since there's no other thread there's no way to make progress), so avoid drop RuntimeTestbed to avoid trigger rocksdb destructor might help.
Update: work around by set thread to 4 at drop rocksdb, i think it's okay to do that since metric recording is already finished at that time |
Codecov Report
@@ Coverage Diff @@
## master #3091 +/- ##
=======================================
Coverage 87.46% 87.46%
=======================================
Files 212 212
Lines 41452 41452
=======================================
Hits 36256 36256
Misses 5196 5196 Continue to review full report at Codecov.
|
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.
Why couldn't we only use it for parameter estimator, i.e, putting this change behind some feature flag?
Actually, I agree with @bowenwang1996 on this. But it also can be useful not only for param estimator, so some generic feature name will be good |
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 should only use the our fork of rocksdb when the single thread feature is enabled.
@@ -10,7 +10,7 @@ log = "0.4" | |||
failure = "0.1" | |||
failure_derive = "0.1" | |||
lazy_static = "1.4" | |||
rocksdb = "0.14" | |||
rocksdb = { git = "https://github.com/nearprotocol/rust-rocksdb", branch="disable-thread" } |
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.
why?
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 use facebook/rocksdb#7191 (merged, but rust-rocksdb haven't bump version) and rust-rocksdb/rust-rocksdb#448 (approved, but need to wait next time rust-rocksdb bump version). Our fork is equal to rust-rocksdb/rust-rocksdb#448
core/store/src/db.rs
Outdated
opts.set_max_total_wal_size(1 * 1024 * 1024 * 1024); | ||
#[cfg(not(feature = "single_thread_rocksdb"))] | ||
{ | ||
println!("Use background threads in rocksdb"); |
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.
Should we remove this log message or convert it into a proper tracing::info/debug/trace?
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.
Seems we didn't log anything in db config module in neard, so I'll remove it to be consistent
env.set_high_priority_background_threads(0); | ||
env.set_low_priority_background_threads(0); | ||
env.set_background_threads(0); | ||
println!("Disabled all background threads in rocksdb"); |
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 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 prefer to keep this one to as print. This is only showup in param estimator, which only used print, one log line between the raw prints looks not good
Thanks to an external contributor, we're able to use all export apis to disable rocksdb threads in runtime param estimator
Test Plan
Observe only one thread during run runtime params estimator