We have a new set of servers running Asterisk 13 on Ubuntu 22.04, where Asterisk eats up more and more RAM daily. On another set of servers running Asterisk 13 on Ubuntu 22.04 this doesn’t happen. I suspect that the issue relates to some specific feature(s) that are being used in Asterisk on the problem servers, but I don’t know what.
We’re reluctant to use Valgrind on busy production servers, but we have recompiled Asterisk with MALLOC_DEBUG enabled, and if I run “sort -n -k 1” on the output of “memory show summary” we get the following. Is anyone able to tell us anything useful from this? I’m not sure what features json.c is used for within Asterisk. Any help would be appreciated!
959848691 bytes in 4264120 allocations in file stasis_channels.c
2057031630 bytes in 35039033 allocations in file json.c
4043204049 bytes allocated (582079734 in caches) in 48132448 selected allocations
4043204049 bytes in all allocations
4043887969 bytes in all allocations and deferred free allocations
Understood, but not possible due to our customer’s requirements. Given that it only happens on some servers and not others I guess the problem relates to specific features. If we can figure out what those features are, then perhaps we can find a workaround.
On Tuesday 24 March 2026 at 00:12:08, dcunningham wrote:
On Monday 23 March 2026 at 23:55:59, seanbright wrote:
This is where you’re told that Asterisk 13 is ancient and you should
upgrade to a supported version.
Understood, but not possible due to our customer’s requirements.
I’m intrigued by this - what requirements does your customer have which cannot
be fulfilled by a current Asterisk version, and only by a release from 12 years
ago?
Antony.
–
90% of networking problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.
They’re running a third party app that depends on a particular version of Asterisk.
Anyway, does anyone have advice on debugging the memory use? @jcolp can we glean anything from the fact that json.c is using a majority of the memory? Thank you.
And this is where when we ask what the name of that 3rd party app is we will get cricket chirps.
Pooh,
99% of the time, the answer to your question is 1 of the 2 following things:
Whatever 3rd party app “requires” an old version of something happens to be an older perpetually licensed something or other that has moved to subscription. For example we have a Cisco UCM and Call Manager app on an old version 10.5 UCM. Neither the app or CM is subscription. They cost nothing every month. To upgrade to a modern version of the call manager app means moving to a monthly subscription on the app which will require a modern version of CM that also requires a monthly subscription. So we either stay with what we have and pay nothing - or we “upgrade” and get no new features and now have to fork over $3k a month. For…nothing. (and yes, I do have a smile on my face every time I get to remind the department manager who wants some feature change on that P.O.S. UCM app that I have a modern Asterisk-based alternative ready and waiting whenever he wants to pull the trigger and retrain his people. I am so looking forward to mucking that Cisco bovine excrement out of the stall)
The customer has made code changes in Asterisk 13 and is unwilling to feed them back to the master open source project. Regardless of your feelings, doing this with F.O.S.S. is perfectly legal as long as they are doing it in house.
In these instances the OP must be told that a) there’s commercial support houses who you can pay to root around in grotty old Asterisk installations and fix this for you without bothering the community who has long since moved on, and b) if you fork a F.O.S.S. project don’t expect support from the community when you selfishly keep your improvements to yourself since that’s pretty much the anthesis of F.O.S.S.
To the OP: take note. Remember this isn’t your circus not your monkeys. Tell your customer they can go broke saving money and there’s a right way to use F.O.S.S. projects and a wrong way and you don’t have to continue going down the wrong path with them.