Re: [ceph-users] Monitoring bluestore compression ratio

Oh, for some reason i thought you'd mentioned the OSD config earlier here. Gald you figured it out anyway! Are you doing any comparison benchmarks with/without compression? There is precious little (no?) info out there about performance impact... Cheers, Blair On 3 Jul. 2018 03:18, "David Turner

Re: [ceph-users] Monitoring bluestore compression ratio

I got back around to testing this more today and I believe figured this out. Originally I set compression_mode to aggressive for the pool. The OSDs themselves, however, had their compression mode set to the default of none. That means that while the pool was flagging the writes so that they shou

Re: [ceph-users] Monitoring bluestore compression ratio

Default OSD settings for compression and the pool has `compression_mode: aggressive`. From my understanding, that should not bother compressing anything except for the specific pool. First I tested this with an EC data pool, but it didn't compress anything. I thought this might be a thing with E

Re: [ceph-users] Monitoring bluestore compression ratio

And yes - first 3 parameters from this list are the right and the only way to inspect compression effectiveness so far. Corresponding updates to show that with "ceph df" are on the way and are targeted for Nautilus. Thanks, Igor On 6/26/2018 4:53 PM, David Turner wrote: ceph daemon osd.

Re: [ceph-users] Monitoring bluestore compression ratio

Hi David, First of all 'bluestore_extent_compress' is unrelated to data compression - that's amount of merged onode's extent map entries. When BlueStore detects neighboring extents in an onode - it might merge them into a single map entry, e.g. write 0x4000~1000 ... ... write 0x5000~20

Re: [ceph-users] Monitoring bluestore compression ratio

In the same pool with compression enabled, I have a 1TB RBD filled with a 10GB /dev/urandom file repeating through the entire RBD. Deleting both of these RBDs didn't change the number of bluestore_extent_compress. I'm also pretty certain that's the same number I saw there before starting these t

Re: [ceph-users] Monitoring bluestore compression ratio

Hi, Zeros are not a great choice of data for testing a storage system unless you are specifically testing what it does with zeros. Ceph knows that other higher layers in the storage stack use zero-fill for certain things and will probably optimise for it. E.g., it's common for thin-provisioning sy

Re: [ceph-users] Monitoring bluestore compression ratio

ceph daemon osd.1 perf dump | grep bluestore | grep compress "bluestore_compressed": 0, "bluestore_compressed_allocated": 0, "bluestore_compressed_original": 0, "bluestore_extent_compress": 35372, I filled up an RBD in a compressed pool (aggressive) in my test clust

Re: [ceph-users] Monitoring bluestore compression ratio

Finally, I've founded the command: ceph daemon osd.1 perf dump | grep bluestore And there you have compressed data Regards, Rafał Wądołowski http://cloudferro.com/ On 04.12.2017 14:17, Rafał Wądołowski wrote: Hi, Is there any command or tool to show effectiveness

[ceph-users] Monitoring bluestore compression ratio

Hi, Is there any command or tool to show effectiveness of bluestore compression? I see the difference (in ceph osd df tree), while uploading a object to ceph, but maybe there are more friendly method to do it. -- Regards, Rafał Wądołowski ___ ce