[pve-devel] applied: [RFC pve-qemu] disable jemalloc

[DERUMIER, Alexandre]

Hi,
sorry for bumping this old thread.

I'm currently benching again qemu with librbd and memory allocator.


It's seem that they are still performance problem with default glibc
allocator, around 20-25% less iops and bigger latency.

From my bench, i'm around 60k iops vs 80-90k iops with 4k randread.

Redhat have also notice it
https://bugzilla.redhat.com/show_bug.cgi?id=1717414
https://sourceware.org/bugzilla/show_bug.cgi?id=28050


I known than jemalloc was buggy with rust lib  && pbs block driver,
but did you have evaluated tcmalloc ?


Note that it's possible to load it dynamically with LD_PRELOAD,
so maybe could we add an option in vm config to enable it ? 



Le mardi 15 décembre 2020 à 14:43 +0100, Thomas Lamprecht a écrit :
> On 10.12.20 16:23, Stefan Reiter wrote:
> > jemalloc does not play nice with our Rust library (proxmox-backup-
> > qemu),
> > specifically it never releases memory allocated from Rust to the
> > OS.
> > This leads to a problem with larger caches (e.g. for the PBS block
> > driver).
> > 
> > It appears to be related to this GitHub issue:
> > https://github.com/jemalloc/jemalloc/issues/1398
> > 
> > The background_thread solution seems weirdly hacky, so let's
> > disable
> > jemalloc entirely for now.
> > 
> > Signed-off-by: Stefan Reiter <s.reiter at proxmox.com>
> > ---
> > 
> > @Alexandre: you were the one to introduce jemalloc into our QEMU
> > builds a long
> > time ago - does it still provide a measurable benefit? If the
> > performance loss
> > would be too great in removing it, we could maybe figure out some
> > workarounds as
> > well.
> > 
> > Its current behaviour does seem rather broken to me though...
> > 
> >  debian/rules | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > 
> 
> applied, thanks!
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>