Re: Thoughts on rocksdb and erasurecode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Why are you selected this specific sizes? Are there any tests/research on it?


Best Regards,

Rafał Wądołowski

On 24.06.2019 13:05, Konstantin Shalygin wrote:

Hi

Have been thinking a bit about rocksdb and EC pools:

Since a RADOS object written to a EC(k+m) pool is split into several 
minor pieces, then the OSD will receive many more smaller objects, 
compared to the amount it would receive in a replicated setup.

This must mean that the rocksdb will also need to handle this more 
entries, and will grow faster. This will have an impact when using 
bluestore for slow HDD with DB on SSD drives, where the faster growing 
rocksdb might result in spillover to slow store - if not taken into 
consideration when designing the disk layout.

Are my thoughts on the right track or am I missing something?

Has somebody done any measurement on rocksdb growth, comparing replica 
vs EC ?

If you want to be not affected on spillover of block.db - use 3/30/300 GB partition for your block.db.



k


_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux