libc malloc alternatifleri

Giriş

libc dışında alternatif olarak kullanılabilecek başka heap kütüphaneleri de mevcut.

gnu malloc Problemi Nedir?

Açıklaması şöyle

Under the hood, GNU malloc uses various data structures to make memory allocations more efficient. One such data structure is a collection of heaps. When the application calls malloc, one of these heaps is searched for a contiguous free chunk of memory big enough to fit the request. When the application calls free, a chunk of the heap frees up, which can be reused by a future malloc call. An important detail is that only the topmost chunk of each heap is available for returning to the OS. All empty chunks in the middle of heaps will technically be unused, but still count towards the memory the application is using. This is a very simplified view of what’s happening; check the glibc wiki for a complete overview of GNU malloc internals.

Şeklen şöyle

Bu da aslında bazen fazla bellek kullanılmasına sebep oluyor. Açıklaması şöyle. Kullanılan bellek oranı mallinfo() çağrısı ile görülebilir. gdb ile bağlanıp mallinfo() yapmak gerekiyor.

As you might imagine, there could be many chunks in the malloc heaps just sitting around empty, depending on the pattern of malloc and free calls an application executes. At this point we were wondering if this kind of memory fragmentation could explain the Fulfillment Service’s ever growing memory usage. While investigating possible ways to confirm this, we happened upon an excellent article from the LinkedIn engineering team, describing a problem extremely similar to ours. However, instead of using the gdb-heap tool the LinkedIn team used, we decided to confirm our hypothesis in a slightly more direct way.

It turns out that GNU malloc already exposes some statistics which are suitable for roughly quantifying memory fragmentation. The statistics we are interested in are: the total size of memory in use by the application, the total size of memory in malloc’s heaps but not in use by the application and the part of that memory allowed to be returned to the OS. GNU malloc’s mallinfo function returns these as the uordblks, fordblks and keepcost fields respectively. So, calculating 1 — uordblks / (fordblks — keepcost) gives the ratio of unused memory that cannot be returned to the OS, a measure of memory fragmentation.

Bu çağrının döndürdüğü şey şeklen şöyle

gdb ve java birlikte kullanımı için açıklama şöyle

Having learned this, we created a local testing setup of the Fulfillment Service. This setup consisted of a Docker container with gdb (the GNU debugger for debugging native code), OpenJDK with debug symbols and glibc with debug symbols. This setup allowed us to attach gdb to the JVM and call the mallinfo function from the gdb prompt.

1. jemalloc

github sayfası burada. Açıklaması şöyle. Eğer MALLOC_CONF değişkeni atanırsa, uygulama .heap uzantılı dosyalar üretir, bu dosyalar jeprof komutu ile okunaklı hale getirilebilir.

These two functions, malloc and free, are implemented in their own library. The default on most flavors of Linux is GNU malloc, but it can be swapped out for other implementations. One such implementation is jemalloc, which conveniently also allows tracking where malloc is being called from. This gives us the opportunity to see whether there are any native functions allocating increasing amounts of memory.

On Linux, jemalloc can be enabled by bundling its shared library with an application and setting the LD_PRELOAD environment variable to the location of libjemalloc.so before running Java. Memory profiling can be enabled through the MALLOC_CONF environment variable. The jemalloc wiki contains some useful examples. You can check the jemalloc man page for a full reference of these options. Now our application writes .heap files after a set volume of allocations. These files can be parsed using the jeprof command into something human-readable.

jemalloc ile ilgili bir başka açıklama şöyle. jemalloc tüm malloc() çağrılarını takip etmiyor ancak örnekleme yapıyor.

Jemalloc only samples memory allocations instead of measuring every single malloc call to prevent excessive resource consumption. Therefore, the output of jeprof cannot be directly interpreted as the number of bytes currently in use. However, it does allow us to spot any suspicious functions allocating native memory. Additionally, we could also spot functions that are holding on to significantly more memory relative to others (potentially indicating a memory leak).

Örnek

Şöyle yaparız

export LD_PRELOAD=/usr/local/lib/libjemalloc.so

# tell jemalloc to write a profile to the disk every few 1Gb allocations 
# and record a stack trace (referenced from the blog):
export MALLOC_CONF=prof:true,lg_prof_interval:30,lg_prof_sample:17

# jeprof*.heap. isimli dosyalar oluşur
# dosyalardan rapor oluştur
jeprof --show_bytes --gif /path/to/jvm/bin/java jeprof*.heap > /tmp/app-profiling.gif

2. tcmalloc
Örneğin TCMalloc google tarafından kullanılıyor.

$ LD_PRELOAD="/usr/lib/libtcmalloc.so"yaparak yeniden derlemeye ihtiyaç duymadan kullanılabilir. Açıklaması şöyle.

TCMalloc assigns each thread a thread-local cache. Small allocations are satisfied from the thread-local cache. Objects are moved from central data structures into a thread-local cache as needed, and periodic garbage collections are used to migrate memory back from a thread-local cache into the central data structures.