This prompts a question that isn't really related to the problem, but I have wondered for some time:

What are the downsides of removing PKG_MALLOC and using the libc allocator? It seems like it would provide unlimited package memory and remove the need to manage it, but I assume there is a reason why this is not done by default.

-- Alex

On Jan 5, 2023, at 3:11 AM, Henning Westerholt hw@gilawa.com wrote:

Hi Juha,

there have been some changes related to that modules indeed for the latest release.

Using memory debugging (http://www.kamailio.org/wiki/tutorials/troubleshooting/memory), in particular the statistics and/or memory dump will probably show the place where its allocated. Then we could probably fix it where its needs to be freed as well.

Cheers,

Henning

-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com

-----Original Message----- From: Juha Heinanen jh@tutpro.com Sent: Thursday, January 5, 2023 12:13 AM To: sr-users@lists.kamailio.org Subject: [SR-Users] pkg memory leak when acc module cdr_enabled

In latest stable K release, we noticed pkg memory leak (pgk memory usage increases by each processed call). It turned out that the leak goes away if acc module cdr_enable is not enabled.

Could be a bug in dialog or acc module. Any debug instructions if the bug is not obvious?

-- Juha __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

On Jan 5, 2023, at 9:40 AM, Henning Westerholt hw@gilawa.com wrote:

Hello Alex,

there might be some performance implications by switching to system malloc. There is also easier debugging by internal Kamailio memory manager support.

In this particular example with the leak, Kamailio would use in the end all of the system memory, and the machine out of memory killer will then randomly processes. So the limited memory pool also helps to protect the system against this kind of leaks.

I am in no position to assess the relative efficiencies of various memory allocators. But it seems a bit extraordinary to suppose that a custom allocator is more efficient than the general-purpose libc allocator, although it's obviously possible; some application-specific optimised allocators clearly make this argument (i.e. Redis + jemalloc).

Also, I wonder if the answer to this has changed over 20 years.

Unbounded allocation from leaks can certainly be a problem. But rendering a process useless by running out of (much more limited) package memory (much more quickly) can also be a problem. :-)

-- Alex

Just to add, this paper gives a lot of benchmark results for different allocators and two glibc versions:

https://adms-conf.org/2019-camera-ready/durner_adms19.pdf

It seems that even in 2019 using a special allocator can have some benefits for certain workloads.

Cheers,

Henning

Not the original developer of the memory managers, but, iirc, one of the reasons for private memory manager was to avoid a multi-threading related lock/mutex that is done by system malloc()/free(), which is not necessary for pure multi-process application. I did not analyzed myself, but I guess this is still there if it was a valid assertion in the past. On the other hand, I am not sure of its relevant impact, a lot of modules link with external libs that use anyhow the system allocator.

Another thing was (faster?) indexing of free fragments up to 16kb that would enable quick selection of a such fragment that would usually fit in a (classic) SIP request/reply or attributes related to them. But I think this is no much relevant these days, because of the auto-join (merge) of free fragments -- without the latter, there were fragmentation problems. Split of large fragments is quite fast.

Then, the ability to add own troubleshooting mechanism, with special structures at the beginning and the end of allocated chunks to track the place from where the chunk was allocated/freed and detect buffer overflows by checking the overwriting of special guard values. This is something that I kind of find still pretty useful for troubleshooting and usage statistics. But this can be implemented as a new memory manager for pkg-only that uses behind directly system malloc()/free(), it is actually in my to-do list for long time, but it didn't materialized yet due to lack of spare time (or from another perspective: lack of funding :-) ).

At this moment, if you install from sources, just do:

make MEMPKG=sys include_modules="..." ... cfg make all make install

and you get kamailio compiled to use system malloc()/free() instead of the custom pkg qm/fm/... manager. I do it when I perform static code analysis, because it enables pkg memory leak detections by those tools. So it should be fully functional, on the other hand, I don't think I run such instance in production at this moment -- there are no pkg usage stats available.

For shm, the custom manager has to be kept, it is still complex to work directly with shared memory, even now most of deployments are on linux, no longer common to have sunos, solaris, vax vms, aix, ... like in early 2000s.

Cheers, Daniel

On 05.01.23 16:57, Alex Balashov wrote:

Thanks, that's educational.

I assumed the original argument was performance-related. I just wasn't sure if that was still (sufficiently to be important) true. After all, lots of SER/OpenSER design decisions in the early 2000s made the most sense then, like inventing own imperative scripting language. :-)

-- Alex

...

On Jan 5, 2023, at 10:16 AM, Henning Westerholt hw@gilawa.com wrote:

(adding sr-dev)

Hi Alex,

the memory allocator of glibc was not really efficient regarding the particular needs of a SIP server (allocation of many small string objects). That has probably improved in the last years, also system performance just got much faster.

Other programs/tools also use their own allocators, e.g. Firefox, Rust [1] for jemalloc.

There is some (not really well tested) support in the core for using the system memory allocator by the #define SYS_MALLOC.

It probably needs to be set in Makefile.defs, also deactivating the other PKG memory managers, but did not looked into it right now.

Cheers,

Henning

[1] https://news.ycombinator.com/item?id=8612645

-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com

-----Original Message----- From: Alex Balashov abalashov@evaristesys.com Sent: Thursday, January 5, 2023 3:59 PM To: Henning Westerholt hw@gilawa.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] pkg memory leak when acc module cdr_enabled

...

On Jan 5, 2023, at 9:40 AM, Henning Westerholt hw@gilawa.com wrote:

Hello Alex,

there might be some performance implications by switching to system malloc. There is also easier debugging by internal Kamailio memory manager support.

In this particular example with the leak, Kamailio would use in the end all of the system memory, and the machine out of memory killer will then randomly processes. So the limited memory pool also helps to protect the system against this kind of leaks.

I am in no position to assess the relative efficiencies of various memory allocators. But it seems a bit extraordinary to suppose that a custom allocator is more efficient than the general-purpose libc allocator, although it's obviously possible; some application-specific optimised allocators clearly make this argument (i.e. Redis + jemalloc).

Also, I wonder if the answer to this has changed over 20 years.

Unbounded allocation from leaks can certainly be a problem. But rendering a process useless by running out of (much more limited) package memory (much more quickly) can also be a problem. :-)

-- Alex

-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

---

Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-leave@lists.kamailio.org

On 05.01.23 23:20, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

is it the latest stable point version 5.6.2, or the latest version from branch 5.6?

Latest from 5.6. I just built new Debian package like this:

MEMDBG=1 $(MAKE) FLAVOUR=kamailio cfg prefix=/usr cfg_prefix=$(BASEDIR) ...

-I does not show DBG_QM_MALLOC. Instead DBG_SR_MEMORY is shown. Is is the same thing and the Memory Manager Debugging instructions are old?

...

Is it accounting done to database, syslog or radius?

Accounting is to syslog.

I found a related patch that was not backported -- I just pushed to 5.6 branch a bunch of commits, including that one. Try again with latest 5.6 branch and report if there is still some issue.

Cheers, Daniel

On 09.01.23 22:54, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

I found a related patch that was not backported -- I just pushed to 5.6 branch a bunch of commits, including that one. Try again with latest 5.6 branch and report if there is still some issue.

Daniel,

Thanks, in lab tests the leak was gone. Will try in production later.

OK, good to know it's gone.

Cheers, Daniel