Take Control of Linux Core File Size

Note: c-treeACE became Faircom DB in November 2020.

During testing and debugging, it has been observed that newer Linux versions have produced noticeably larger core files than would be expected from memory usage statistics. A core file is normally close to the size of the process’s working memory space. A bit of research has turned up a somewhat surprising finding many of our Linux users, glibc users in particular, should be aware of.

The C runtime (GLIBC >= 2.10) now allocates a new heap for each thread on its first memory allocation call, and each heap is 64 MB. This behavior can be reproduced with a small test program. Create a thread and have it sleep without callingmalloc(), and process memory use increases only by the thread’s stack size. However, if your thread calls malloc(), process memory use increases by about 64 MB. This is by design with newer versions of glibc (>=2.10).

• Malloc per-thread arenas in glibc
• Linux glibc >= 2.10 (RHEL 6) malloc may show excessive virtual memory usage

This change was introduced for scalability purposes. Allocating a separate heap for each thread reduces contention between the threads up to a limited number of threads. The creation of new heaps is limited to 8 times your CPU core count (64-bit systems) or 2 times your CPU core count (32-bit systems).

You can modify this behavior via an environment variable visible to your process. Set MALLOC_ARENA_MAX to 1 before starting FairCom DB, then only one heap is created for your process, and observed memory use appears as may be expected, that is, process size plus any memory allocations. This must be done before the first malloc() call.

It is also possible to call mallopt() to change MALLOC_ARENA_MAX directly in your application. Example:

#include <malloc.h>

...

mallopt(M_ARENA_MAX, 1);

...

FairCom engineers are studying whether to include a FairCom DB configuration option and allow modifying this value such that it is tunable for specific applications. If performance profiling indicates appreciable gains can be found, look for this change in a future FairCom DB release. In the meantime, you may wish to explore how this impacts your specific c‑tree database applications.