SSD (block.db) partition contains object metadata in RocksDB so it
probably loads the metadata before modifying objects (if it's not in
cache yet). Also it sometimes performs compaction which also results in
disk reads and writes. There are other things going on that I'm not
completely aware of. There's the RBD object map... Maybe there are some
locks that come into action when you parallel writes...
There's a config option to enable RocksDB performance counters. You can
have a look into it.
However if you're just trying to understand why RBD isn't super fast
then I don't think these reads are the cause...
Hi Vitaliy
Yes - I tried this and I can still see a number of reads (~110 iops,
440KB/sec) on the SSD, so it is significantly better, but the result
is still puzzling - I'm trying to understand what is causing the
reads. The problem is amplified with numjobs >= 2 but it looks like it
is still there with just 1.
Like some caching parameter is not correct, and the same blocks are
being read over and over when doing a write?
Could anyone advise on the best way for me to investigate further?
I've tried strace (with -k) and 'perf record' but neither produce any
useful stack traces to help understand what's going on.
Regards
--
Brad
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
