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 <h...@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 <abalas...@evaristesys.com> > Sent: Thursday, January 5, 2023 3:59 PM > To: Henning Westerholt <h...@gilawa.com> > Cc: Kamailio (SER) - Users Mailing List <sr-us...@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 <h...@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-le...@lists.kamailio.org
