On Thu, 16 Feb 2017, Wido den Hollander wrote: > > Op 16 februari 2017 om 15:24 schreef Sage Weil <sweil@xxxxxxxxxx>: > > > > > > On Thu, 16 Feb 2017, Ruiz Alonso, Jaime Jesus (Nokia - ES) wrote: > > > > > > Thanks a lot for your help, > > > > > > We left the test running with this change ( bluefs_buffered_io set to true ) > > > and we observed a radical increase on performance. > > > > > > Effects of the change on our only write test: > > > > > > - No reads from disk ( before change were in the 500 r/s range ) > > > - Minimum Write bandwidth moved from 12 MBps to 24 MBps > > > > > > Attached Sheet "Test1-2_Kraken_11.2_iotrue" in the xls. > > > > > > See attached pictures. > > > > > > Best Regards, > > > Jaime > > > > Thanks for testing! This suggests to me that even a simple LRU write > > buffer cache in bluefs to catch recently compacted SSTs will be enough to > > prime the rocksdb kv cache. Either that or we need to do the same in > > rocksdb itself, but they didn't seem very interested in doing that in the > > general case. Our situation is a bit atypical in that we'd prefer to > > eliminate the dependence on the OS page cache so that we can work with > > SPDK. > > > > What would be the true downside of setting bluefs_buffered_io to true in > the default config? For now, I think none. I'll change the default until we have a better solution. I was hoping we could get by without it but it seems not! Eventually I want ot remove the buffered code entirely, though, which means we need to get the same caching behavior in some other way. I think it will be pretty easy to do that in bluefs, though, with minimal code. sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
