[Home]

Summary:ASTERISK-17752: (not so)large astDB key values cause asterisk to take up a lot of memory
Reporter:Jacco van Tuijl (jacco)Labels:
Date Opened:2011-04-26 04:46:55Date Closed:2015-03-13 19:02:43
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_db
Versions:1.8.3 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I've been testing astDB limits in combination with asterisk.

a simple dialplan :
{noformat}
exten = _X.,n(waiting),Set(DB(test/testing)=${DB(test/testing)}a)
exten = _X.,n,goto(waiting)
{noformat}
made the value length grow up to max. 4096bytes causing asterisk to take up 84% memory on a machine with 4gb ram

also in one of the test a whitespace came out of nowhere:
http://pastebin.com/gpbpcjzR
Comments:By: Matt Jordan (mjordan) 2015-03-13 18:41:14.368-0500

I tested this again on Asterisk 11. I was unable to reproduce the extraneous 'whitespace' character.

Asterisk pegging a CPU in this test case is *not* a bug. You've put a channel into an infinite loop where nothing causes it to stop hogging a processor. Ergo, it hogs a processor. This is the same with anything put into an infinite loop that continually processes data.
By: Matt Jordan (mjordan) 2015-03-13 18:45:51.244-0500

Apologies, I completely read this wrong as "CPU" and not "memory". Memory usage does, indeed, continue to grow, even on Asterisk 11. Reopening!
By: Matt Jordan (mjordan) 2015-03-13 19:02:30.353-0500

And, still not a bug :-)

I was able to reproduce this using Asterisk 11 and with Verbosity enabled going to the CLI. Memory usage in Asterisk kept increasing as the channel spammed itself. However, upon some additional investigation, this was due to log messages showing the infinite loop executing getting queued up and dispatched to the CLI.

Running Asterisk without verbosity results in no memory increasing for the process, even as the channel spams the AstDB and pegs a CPU. But again, the channel is in an infinite loop, so that's expected.