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

some questions about paper #1

Open
suxiao111 opened this issue Feb 17, 2020 · 9 comments
Open

some questions about paper #1

suxiao111 opened this issue Feb 17, 2020 · 9 comments

Comments

@suxiao111
Copy link

Hi,How did you experiment with bandwidth and CPU utilization for RocksDB?One more question,How is the time ratio of each step of the RocksDB in the merge process calculated? Thanks~

@BLepers
Copy link
Owner

BLepers commented Feb 17, 2020

Hi,

Thanks for your interest.

We modified the db_bench tool to run YCSB in RocksDB. The code of the bench is here: https://github.com/theoanab/SILK-USENIXATC2019 (tools/db_bench_tools.cc). We configured the number of injection/compaction threads to saturate the CPU (number of threads must be significantly higher than number of cores).

For the ratios, we used perf. Percentages are directly what's reported by perf report.

@suxiao111
Copy link
Author

Hi,
ok, I've got it. Thank you very much for your reply!

@suxiao111
Copy link
Author

Hi,
In your paper,Figure 3 shows the disk utilization and the CPU utilization on Config-Optane for RocksDB and Wired Tiger. Both systems saturate the CPU and do not take full advantage of the available bandwidth. And Figure 4 shows the throughput fluctuation over time for RocksDB and for WiredTiger.I have some questions:

  1. What is the relationship between the bandwidth in Figure 3 and the throughput in figure 4?How is the maximum IO bandwidth value obtained in Figure 3?
    2.Figure 4 shows that RocksDB sustains on average 63K requests/s ,and the KV-item size is1KB ,so RocksDB sustains on average 63KB/s.But Figure 3 shows that RocksDB sustains on average 600KB/s.

Thank you very much~

@BLepers
Copy link
Owner

BLepers commented Mar 1, 2020

1/ We measure the IO bw using iostat, and throughput directly in the systems. When IO goes up, throughput goes down.
2/ The 63MB/s -> 600MB/s is due to compactions (write amplification is a good keyword to search for :) )

@suxiao111
Copy link
Author

Yeah, thanks,write magnification is a serious matter, but the experimental setup and the benchmark in figure 3 and figure 4 is the same.They just have different experimental observation indexes(bw&throught).Because the KV-item size is1KB ,so I think the two values should be equal?

@BLepers
Copy link
Owner

BLepers commented Mar 1, 2020

If RocksDB has a 10x write amplification, then 1KB translate into 10KB used BW. That's what we measure (disk level bandwidth). Or am I missing something in your question?

@suxiao111
Copy link
Author

Yeah, thanks,Maybe I'm not making it clear.
Actually, The experimental setup in figure 3 and figure 4 is the same,including same system and same benchmark.
Take RocksDB for example, Figure 3 shows that RocksDB sustains on average 600KB/s.But Figure 4 shows that RocksDB sustains on average 600KB/s?

@BLepers
Copy link
Owner

BLepers commented Mar 9, 2020

I am not sure to understand your question. One figure shows the throughput (requests/s), and the other one the disk usage (MB/s). The disk usage is due to RocksDB writing updates (commit log + flushing the memory component), and performing compaction. You cannot guess the throughput from the disk usage or vice versa, it is very dependant on the workloads and timings. For instance, if a key is updated twice, the disk usage will be lower than if two different keys are updated, but the throughput will be the same. Not sure what you are trying to measure here.

@suxiao111
Copy link
Author

Good.! Your example is very specific. I understand what you mean.That's a good idea!
Thank you very much~

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants