On 9/23/20 8:23 AM, George Shuklin wrote:
I've just finishing doing our own benchmarking, and I can say, you
want to do something very unbalanced and CPU bounded.
1. Ceph consume a LOT of CPU. My peak value was around 500% CPU per
ceph-osd at top-performance (see the recent thread on 'ceph on brd')
with more realistic numbers around 300-400% CPU per device.
In fact in isolation on the test setup that Intel donated for
community ceph R&D we've pushed a single OSD to consume around 1400%
CPU at 80K write IOPS! :) I agree though, we typical see a peak of
about 500-600% CPU per OSD on multi-node clusters with a
correspondingly lower write throughput. I do believe that in some
cases the mix of IO we are doing is causing us to at least be
partially bound by disk write latency with the single writer thread
in the rocksdb WAL though.
I'd really like to see how they done this without offloading (their
configuration).
I went back and looked over some of the old results. I didn't find the
really high test scores (and now that I'm thinking about it they may
have been from when I was ripping out pglog OMAP updates!), but here's
one example I did find from earlier testing last winter that at least
got into roughly the right ballpark with stock master from last December
(~66K IOPS):
Avg 4K FIO randwrite IOPS: 65841.7
- 1 p4510 NVMe backed OSD
- 8GB osd memory target
- 4K min alloc size
- 4 clients, 1 128GB RBD volume per client, io_depth=128, time=300s
- 128 PGs (fixed)
- latency-network tuned profile
- bluestore_rocksdb_options =
"compression=kNoCompression,max_total_wal_size=1073741824,max_write_buffer_number=16,min_write_buffer_number_to_merge=3,recycle_log_file_num=4,write_buffer_size=67108864,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,max_background_compactions=2,compaction_style=kCompactionStyleUniversal"
- bluestore_default_buffered_write = true
- bluestore_default_buffered_read = true
- rbd cache = false
Beyond that general stuff like background scrubbing and pg autoscaling
was disabled. I should note that these results are using universal
compaction in rocksdb which you probably don't want to do in production
because it can require 2x the total DB space to perform a compaction.
It might actually be feasible now that we are doing column family
sharding thanks to Adam's PR because you will only need 2x the space of
any individual column family for compaction rather than the whole DB,
but it's still unsupported for now.
Mark
2. Ceph is unable to deliver more than 12k IOPS per ceph-osd (may be
a little more with top-tier low-core high-frequency CPU, but not
much). So, super-duper-nvme wont make difference. (btw, I have a
stupid idea to try to run two ceph-osd from the same LV with a
single PV underneath VG, but it not tested).
I'm curious if you've tried octopus+ yet? We refactored bluestore's
caches which internally has proven to help quite a bit with latency
bound workloads as it reduces lock contention in onode cache shards
and the impact of cache trimming (no more single trimming trim thread
constantly grabbing the lock for long periods of time!). In a 64
NVMe drive setup (P4510s), we were able to do a little north of 400K
write IOPS with 3x replication, so about 19K IOPs per OSD once you
factor rep in. Also, in Nautilus you can see real benefits wtih
running multiple OSDs on a single device but with Octopus and master
we've pretty much closed the gap on our test setup:
It's octopus. I was doing single-osd benchmark, removing all movable
parts (brd instead of nvme, no network, size=1, etc). Moreover, I've
focused on rados benchmark, as RBD is just a derivative from rados
performance.
Anyway, big thank you for input.
https://docs.google.com/spreadsheets/d/1e5eTeHdZnSizoY6AUjH0knb4jTCW7KMU4RoryLX9EHQ/edit?usp=sharing
Generally speaking using the latency-performance or latency-network
tuned profiles helps (mostly due to avoid C state CPU transitions) as
does higher clock speeds. Not using replication helps but that's
obviously not a realistic solution for most people. :)
I used size=1 and 'no ssd, no network' as upper bound. If allows to
find limits for ceph-osd performance. Any real-life things
(replication, network, real block devices) will make things worse, not
better. Knowing upper performance bound is really nice when start to
choose server configuration.
3. You wll find that any given client performance is heavily limited
by sum of all RTT in the network, plus own latencies of ceph, so
very fast NVME give a diminishing return.
4. CPU bounded ceph-osd completely wipe any differences for
underlying devices (except for desktop-class crawlers).
You can run your own tests, even without fancy 48-nvme boxes - just
run ceph-osd on brd (block ram disk). ceph-osd won't run any faster
on anything else (ramdisk is the fastest), so numbers you get from
brd is supremum (upper bound) for theoretical performance.
Given max 400-500% CPU per ceph-osd I'd say you need to keep number
of NVME in server below 12, or, 15 (but sometimes you'll get CPU
saturation).
In my opinion less fancy boxes with smaller number of drives per
server (but larger number of servers) would make your (or your
operation team's) life much less stressful.
That's pretty much the advice I've been giving people since the
Inktank days. It costs more and is lower density, but the design is
simpler, you are less likely to under provision CPU, less likely to
run into memory bandwidth bottlenecks, and you have less recovery to
do when a node fails. Especially now with how many NVMe drives you
can fit in a single 1U server!
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
