[pve-devel] qemu + tcmalloc for rbd
DERUMIER, Alexandre
alexandre.derumier at groupe-cyllene.com
Wed Jan 10 19:29:21 CET 2024
Am 10/01/2024 um 10:12 schrieb Fiona Ebner:
> Am 09.01.24 um 18:02 schrieb DERUMIER, Alexandre:
> > Another way (maybe safer), is to build 2 binary in same package
> > (/usr/bin/kvm-tcmalloc && /usr/bin/kvm), and give option to user
> > to
> > choose it.
> >
>
> If we go for this route, I'd rather have two conflicting packages to
> avoid the redundant space usage for most people. Or if we really want
> to
> support being able to use both on a single system, an add-on kind of
> package with just the second binary.
>>I would like to avoid both, an extra package or an extra binary, as
>>both are a significant overhead for both us to maintain and user to
>>work with.
>>
>>Either tcmalloc works as allocator and is an actual improvement
>>overall,
>>in which case we should unconditionally use it, or it doesn't work,
>>or is
>>no improvement, in which case it makes no sense to expose it.
Yes, I totally understand that. If user have problems (maybe not
related to allocator), it'll need to all tests x2 to debug
(iothreads,..).
>>IME changing allocator is nice for some specific benchmarks, but
>>overall
>>there often even are some regressions in other configurations..
Personnaly, I really see a big difference on real workload with
latencies. (where latencies is really where ceph can be slow)
>>We e.g. tested different allocators extensively when debugging some
>>memory growth during PBS backups, none of the shiny alternatives was
>>really any better, thus we resulted to triggering explicit trims.
yes, I remember of that. I don't use PBS, so I can't comment about
this.
Do you have more information about how to reproduce this ?
I could take some test tcmalloc again with pbs backups.
More information about the pve-devel
mailing list