Hi Roman,
On Sat, Jan 11, 2020 at 4:49 PM Roman Penyaev <rpenyaev(a)suse.de> wrote:
Then taking into account everything you've said
what load is a win
for crimson? What exactly should I run to notice that all shiny things
which seastar provides actually work and bring a value?
I usually go with 4 KB random reads using `rados bench`. For the main
path It should generate workload very similar to RBD while being much
more efficient generator than FIO. The former requires a fair amount of
CPUs which can be restricting when doing quick dev tests with multiple
instances (crimson requires at least two to saturate) on a HW with
limited CPU count.
(and I talk
about iops, because that's actually what matters for storage after all).
This requires clarification. IOPS from single OSD instance or from
a set of HW? I think that all finally matters is return-on-investment.
Number of processes inside a box is an implementation detail.
I just want to run a simple benchmark, which can show
me a clear
difference in iops numbers between legacy and crimson osd.
Sure. Currently we have the `perf check bot` doing `scripts/run-cbt.sh`
on `crimson-osd` to hunt for regressions. However, deploying
environment might be a bit time-consuming, so I quickly & roughly
compared both OSD implementations in the old school way:
https://gist.github.com/rzarzynski/9f92f951c929d4a4ed9a7a13ff156b71
All commands all there. I would be grateful for verifying the results.
Regards,
Radek