public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* Questions about the heap manager in glibc
@ 2023-08-16 13:51 Florian Kramer
  0 siblings, 0 replies; only message in thread
From: Florian Kramer @ 2023-08-16 13:51 UTC (permalink / raw)
  To: libc-help

[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

Hi,

I ran into some unexpected behaviour while writing c++ code, and wanted to try and understand what was happening.
We are using an `std::unordered_map` and inserting lots of data into it, resulting in about 1-2 GiB being used just by
the map in our small-scale tests. The map uses the default std::allocator, which in turn uses malloc and free from glibc (according
to a quick google. We also tried a custom allocator which definitely just used malloc and free).
After the map is destructed and free is called on all the allocated chunks of memory (There are a lot of them. The map seems
to allocated memory in very small chunks) the memory is not returned to the kernel, but instead remains in use by the program.
We are running the software on ubuntu 22.04, so a slightly older linux kernel.

Some reading into how glibc handles allocating and freeing memory shows this is an optimization, as the still held memory can be
returned by a later call to malloc, which is more efficient than returning it to the kernel and reacquiring it. The problem we ran into
in our production environment is that this could lead to over 100GiB of memory being reserved by a single process, without the
memory being in use inside of the application (at least from a cpp point of view). This led to semi-frequent crashes of the software,
as there are several instances spawned through docker on the same machine all using the systems memory.

Our current fix is to just call malloc_trim to release the memory back to the os. I was hoping somebody on this mailing list
could give more insight as to why the heap manager holds on to that much memory in this scenario, and also if calling malloc_trim
is the intended way to handle this, or if there is a preferred method.

Best Regards,
Florian

Florian Kramer

Tel.:

Mail:  f.kramer@dotscene.com<mailto:f.kramer@dotscene.com>

[https://static.dotscene.com/email-signatures/img/image002.png]

dotscene GmbH

Wentzingerstr. 17

79106 Freiburg

Germany

Tel.: +49 761 2163360

Mail: mail@dotscene.com<mailto:mail@dotscene.com>

Web: ?www.dotscene.com<https://www.dotscene.com/>

[https://static.dotscene.com/email-signatures/img/image004.png] <https://de.linkedin.com/company/dotscene-gmbh> [https://static.dotscene.com/email-signatures/img/image006.png]  <https://instagram.com/dotscene_gmbh?utm_medium=copy_link> [https://static.dotscene.com/email-signatures/img/image008.png]  <https://www.xing.com/pages/dotscenegmbh> [https://static.dotscene.com/email-signatures/img/image010.png]  <https://www.facebook.com/dotscenegmbh/>

Geschäftsführer:

Nicolas Trusch

Maryan Wieland

Handelsregister:

HRB 715508

Registergericht:

Amtsgericht Freiburg i.Br.

Unternehmenssitz:

Freiburg i.Br.

Ust-IdNr.:

DE309748553

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly forbidden.

dotscene_signature_included

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-08-16 13:51 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-16 13:51 Questions about the heap manager in glibc Florian Kramer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).