Global delayed write rate #346
Comments
Guyme
added
enhancement
change write_controller_ of db_impl to pointer
enable sharing the Write Controller across dbs through the db options while still retaining the old behavior. when shared between dbs, the write controller keeps track of all the delay requirements of all cfs in the dbs and enforces on all of them the lowest write rate required. NOTE: plz note that setting a write controller in the options is only valid with use_dynamic_delay = true. Dynamic Delay: CFs wont override each other (#358) Currently, in a setting of multiple cfs, the delayed_write_rate_ value is overridden by the latest cf that entered a delay state. so if a cf registered a delay state that is less severe than the previous cf, it will override the previous value of delayed_write_rate_ with a higher rate than the system should use. fix it by storing the delay requirements of all the CFs in the write controller and only set a new delayed_write_rate_ when its smaller than the min.
enable sharing the Write Controller across dbs through the db options while still retaining the old behavior. when shared between dbs, the write controller keeps track of all the delay requirements of all cfs in the dbs and enforces on all of them the lowest write rate required. NOTE: plz note that setting a write controller in the options is only valid with use_dynamic_delay = true. Dynamic Delay: CFs wont override each other (#358) Currently, in a setting of multiple cfs, the delayed_write_rate_ value is overridden by the latest cf that entered a delay state. so if a cf registered a delay state that is less severe than the previous cf, it will override the previous value of delayed_write_rate_ with a higher rate than the system should use. fix it by storing the delay requirements of all the CFs in the write controller and only set a new delayed_write_rate_ when its smaller than the min.
|
Standard tests are running |
|
Small obj possible improvement with seekrandomwriterandom large Obj no gain no pain Huge DB no improvement in some tests std is even bigger. |
|
@hilikspdb try ro run with 2 CF, with 90/10 distribution. We need better definition. |
|
1) with 2 disks and relatively small cf and object size=1k the write flow
is the limit. please use either 1 disk or else 2K objects or else larger
database to get into the state where the disks are the bottleneck
2) in naked eye I see a difference when we set data smoothing = 1 or 6
(less jumpy)
…On Wed, Mar 1, 2023 at 9:13 AM erez-speedb ***@***.***> wrote:
@hilikspdb <https://github.com/hilikspdb> try ro run with 2 CF, with
90/10 distribution.
Didnt get stalls and didnt get improvments.
/home/ubuntu/speedb/db_bench --compression_type=None -db=/data/
-num=200000000 -value_size=1000 -key_size=16 --delayed_write_rate=536870912
-report_interval_seconds=1 -max_write_buffer_number=4
-num_column_families=2 -histogram -max_background_compactions=8
-cache_size=8388608 -max_background_flushes=4 -bloom_bits=10
-column_family_distribution=90,10 -duration=900 --use_existing_db
-threads=50 -duration=900 -benchmark_read_rate_limit=0
-benchmark_write_rate_limit=0 -report_file=overwrite.csv
--benchmarks=overwrite,levelstats
https://admin.speedb.io/performance?items=cByN7eMAY3xipublUQ9R&items=FF08AyqBUFlqfOE7O3ra&colors=%2300796b&colors=%23BA68C8
We need better definition.
—
Reply to this email directly, view it on GitHub
<#346 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZKTXGF4T2IPXRAWFSTARSDWZ3ZKVANCNFSM6AAAAAATQYMFS4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
the test above fails to show the benefit of always picking the slowest cf since:
|
|
|
@Yuval-Ariel ?? |
|
@erez-speedb , this test also doesnt show the benefits since the only place where the 2nd cf reaches a delay state is in the fillrandom test which has equal distribution. this feature enables the db to use the lowest delay requirement from all cfs and all dbs the wc is connected to. |
|
@Yuval-Ariel per your request 90/10 on all tests. Still nothing visible. |
|
@erez-speedb yes because the 2nd cf didnt reach more than 4 L0 files.. so it didnt reach a delay state. |
|
thanks @erez-speedb for your attempts. i'll run the performance |
|
red - global delay (5e01ba7) more exactly measured by the standard deviation of the ops/sec: cmd to reproduce: |
|
@Guyme , ok to merge? |
|
@Yuval-Ariel - YES! |
enable sharing the Write Controller across dbs through the db options while still retaining the old behavior. when shared between dbs, the write controller keeps track of all the delay requirements of all cfs in the dbs and enforces on all of them the lowest write rate required. NOTE: plz note that setting a write controller in the options is only valid with use_dynamic_delay = true. Dynamic Delay: CFs wont override each other (#358) Currently, in a setting of multiple cfs, the delayed_write_rate_ value is overridden by the latest cf that entered a delay state. so if a cf registered a delay state that is less severe than the previous cf, it will override the previous value of delayed_write_rate_ with a higher rate than the system should use. fix it by storing the delay requirements of all the CFs in the write controller and only set a new delayed_write_rate_ when its smaller than the min.
github-project-automation
bot
moved this from 🏗️ Working on it
to 📖 Need your Opinion!
in Speedb Roadmap
enable sharing the Write Controller across dbs through the db options while still retaining the old behavior. when shared between dbs, the write controller keeps track of all the delay requirements of all cfs in the dbs and enforces on all of them the lowest write rate required. NOTE: plz note that setting a write controller in the options is only valid with use_dynamic_delay = true. Dynamic Delay: CFs wont override each other (#358) Currently, in a setting of multiple cfs, the delayed_write_rate_ value is overridden by the latest cf that entered a delay state. so if a cf registered a delay state that is less severe than the previous cf, it will override the previous value of delayed_write_rate_ with a higher rate than the system should use. fix it by storing the delay requirements of all the CFs in the write controller and only set a new delayed_write_rate_ when its smaller than the min.
enable sharing the Write Controller across dbs through the db options while still retaining the old behavior. when shared between dbs, the write controller keeps track of all the delay requirements of all cfs in the dbs and enforces on all of them the lowest write rate required. NOTE: plz note that setting a write controller in the options is only valid with use_dynamic_delay = true. Dynamic Delay: CFs wont override each other (#358) Currently, in a setting of multiple cfs, the delayed_write_rate_ value is overridden by the latest cf that entered a delay state. so if a cf registered a delay state that is less severe than the previous cf, it will override the previous value of delayed_write_rate_ with a higher rate than the system should use. fix it by storing the delay requirements of all the CFs in the write controller and only set a new delayed_write_rate_ when its smaller than the min.
Allow slowing down writes based on memory consumption by having the WBM raise a delay requirement in the WriteController. The delay requirement is stored in the WC as part of the Global Delay feature (#346). The same way a CF signals the WC that it has a delay requirement.
bosmatt
removed
the
Working on it
enable sharing the Write Controller across dbs through the db options while still retaining the old behavior. when shared between dbs, the write controller keeps track of all the delay requirements of all cfs in the dbs and enforces on all of them the lowest write rate required. NOTE: plz note that setting a write controller in the options is only valid with use_dynamic_delay = true. Dynamic Delay: CFs wont override each other (#358) Currently, in a setting of multiple cfs, the delayed_write_rate_ value is overridden by the latest cf that entered a delay state. so if a cf registered a delay state that is less severe than the previous cf, it will override the previous value of delayed_write_rate_ with a higher rate than the system should use. fix it by storing the delay requirements of all the CFs in the write controller and only set a new delayed_write_rate_ when its smaller than the min.
enable sharing the Write Controller across dbs through the db options while still retaining the old behavior. when shared between dbs, the write controller keeps track of all the delay requirements of all cfs in the dbs and enforces on all of them the lowest write rate required. NOTE: plz note that setting a write controller in the options is only valid with use_dynamic_delay = true. Dynamic Delay: CFs wont override each other (#358) Currently, in a setting of multiple cfs, the delayed_write_rate_ value is overridden by the latest cf that entered a delay state. so if a cf registered a delay state that is less severe than the previous cf, it will override the previous value of delayed_write_rate_ with a higher rate than the system should use. fix it by storing the delay requirements of all the CFs in the write controller and only set a new delayed_write_rate_ when its smaller than the min.
Allow slowing down writes based on memory consumption by having the WBM raise a delay requirement in the WriteController. The delay requirement is stored in the WC as part of the Global Delay feature (#346). The same way a CF signals the WC that it has a delay requirement.
enable sharing the Write Controller across dbs through the db options while still retaining the old behavior. when shared between dbs, the write controller keeps track of all the delay requirements of all cfs in the dbs and enforces on all of them the lowest write rate required. NOTE: plz note that setting a write controller in the options is only valid with use_dynamic_delay = true. Dynamic Delay: CFs wont override each other (#358) Currently, in a setting of multiple cfs, the delayed_write_rate_ value is overridden by the latest cf that entered a delay state. so if a cf registered a delay state that is less severe than the previous cf, it will override the previous value of delayed_write_rate_ with a higher rate than the system should use. fix it by storing the delay requirements of all the CFs in the write controller and only set a new delayed_write_rate_ when its smaller than the min.
Allow slowing down writes based on memory consumption by having the WBM raise a delay requirement in the WriteController. The delay requirement is stored in the WC as part of the Global Delay feature (#346). The same way a CF signals the WC that it has a delay requirement.
What:
Delayed write rate in a system level - shared to all DBs
Why:
The current delayed write mechanism allows the user to set a limit per database.
Databases that have internal delay may be starved by others that work faster
Therefore a write-control for the entire system is requires.
Who:
-This will mostly relevant for systems with multiple DBs.
Requirements:
The text was updated successfully, but these errors were encountered: