[OpenSIPS-Users] Memory Issues because of AVPs?

Duane Larson duane.larson at gmail.com
Wed Apr 6 05:18:23 CEST 2011


OK after more testing it looks like my current test config with
dialoginfo_set();  commented out is stable.  My opensips processes grow to
around 8.1 and 7.9 via the top command and stay there without growing
anymore.  Also I just found the following command

opensipsctl fifo get_statistics pkmem: shmem:

Didn't know about it.  After looking at that I see that I have a good amount
of free memory with all the pkmem's and the shmem.

As for all the records in the PUA table that is probably because I have
edited my script so much just to test calls per second. I had disabled all
my presence processing but forgot to comment out the dialoginfo_set()
function.  Hopefully when I am done stress testing the PUA stuff will not be
an issue.



On Tue, Apr 5, 2011 at 6:02 PM, Duane Larson <duane.larson at gmail.com> wrote:

> Thanks for the reply.  I actually have been following the directions on
>
> http://www.opensips.org/Resources/DocsTsMem
>
>
> Perhaps my memory is building up because I am receiving a ton of the
> following in my PUA database table
>
> mysql> select * from pua;
>
> +--------+------------------+----------------+-------+---------+-----------------+------+------+----------+-------------+--------+---------+--------+----------+------+--------------+---------+----------------+---------+---------------+
> | id     | pres_uri         | pres_id        | event | expires |
> desired_expires | flag | etag | tuple_id | watcher_uri | to_uri | call_id |
> to_tag | from_tag | cseq | record_route | contact | remote_contact | version
> | extra_headers |
>
> +--------+------------------+----------------+-------+---------+-----------------+------+------+----------+-------------+--------+---------+--------+----------+------+--------------+---------+----------------+---------+---------------+
> | 641966 | sip:102 at test.com | DIALOG_PUBLISH |    64 |       0 |
> 1302067600 | 1024 |      |          |             |        |
> |        |          |    0 |              |         |                |
> 0 |               |
> | 642014 | sip:102 at test.com | DIALOG_PUBLISH |    64 |       0 |
> 1302067599 | 1024 |      |          |             |        |
> |        |          |    0 |              |         |                |
> 0 |               |
>
> This is because of the following function in my opensips.cfg script
>
> dialoginfo_set();  (using this so I can have the BLF feature)
>
> When I comment this out my script appears to run fine when I stress test it
> with SIPP.  I have the following
> children = 10
> Server has 1 Gig of RAM
> I configured my config.h to be "define PKG_MEM_POOL_SIZE 4*1024*1024"
> I execute the Opensips service with 128M of memory
>
> I run my SIPP test for about 5 minutes and 30 seconds and get the following
> outcome
>
>   Counter Name           | Periodic value            | Cumulative value
>
> -------------------------+---------------------------+--------------------------
>   Elapsed Time           | 00:00:00:000              |
> 00:05:32:211
>   Call Rate              |    0.000 cps              |   18.455
> cps
>
> -------------------------+---------------------------+--------------------------
>   Incoming call created  |        0                  |
> 0
>   OutGoing call created  |        0                  |
> 6131
>   Total Call created     |                           |
> 6131
>   Current Call           |        0
> |
>
> -------------------------+---------------------------+--------------------------
>   Counter 5              |        0                  |
> 6130
>
> -------------------------+---------------------------+--------------------------
>   Successful call        |        0                  |
> 6130
>   Failed call            |        0                  |        1
>
>
> With this test I have nothing in my PUA table.  Also at the end of this
> test I see that I have the folllowing when I execute the "top" command
>
> Mem:   1022536k total,   785916k used,   236620k free,    29708k buffers
> Swap:  2097148k total,        0k used,  2097148k free,   457508k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 15327 mysql     20   0  333m 183m  10m S    1 18.4   9:24.24 mysqld
>  1084 root      20   0 63012  15m 2788 S    0  1.5   0:00.28
> opensips-mi-pro
>  1096 root      20   0 73296  14m 3128 S    0  1.5   0:00.89
> media-dispatche
> 18654 opensips  20   0  283m  11m 9404 S    0  1.2   0:00.74 opensips
> 18643 opensips  20   0  281m  11m 9464 S    0  1.2   0:01.07 opensips
> 18647 opensips  20   0  281m  11m 9420 S    0  1.2   0:01.10 opensips
> 18646 opensips  20   0  281m  11m 9376 S    0  1.2   0:01.09 opensips
> 18649 opensips  20   0  281m  11m 9320 S    0  1.2   0:01.10 opensips
> 18650 opensips  20   0  281m  11m 9284 S    0  1.1   0:01.12 opensips
> 18651 opensips  20   0  281m  11m 9276 S    0  1.1   0:01.10 opensips
> 18645 opensips  20   0  281m  11m 9272 S    0  1.1   0:01.10 opensips
> 18644 opensips  20   0  281m  11m 9140 S    0  1.1   0:01.10 opensips
> 18648 opensips  20   0  281m  11m 9076 S    0  1.1   0:01.08 opensips
> 18652 opensips  20   0  281m  11m 8972 S    0  1.1   0:01.11 opensips
> 18639 opensips  20   0  281m 8360 6096 S    0  0.8   0:00.09 opensips
> 18640 opensips  20   0  283m 4120 1500 S    0  0.4   0:00.08 opensips
> 18656 opensips  20   0  283m 4044 1760 S    0  0.4   0:00.12 opensips
> 18641 opensips  20   0  281m 3448 1144 S    0  0.3   0:00.00 opensips
> 18642 opensips  20   0  281m 3224  960 S    0  0.3   0:00.00 opensips
> 18655 opensips  20   0  281m 3208  940 S    0  0.3   0:00.07 opensips
> 18653 opensips  20   0  281m 2320   88 S    0  0.2   0:00.51 opensips
>
>
>
>
> Then I run a second test with SIPP and get the following
>   Counter Name           | Periodic value            | Cumulative value
>
> -------------------------+---------------------------+--------------------------
>   Elapsed Time           | 00:00:00:000              |
> 00:13:35:590
>   Call Rate              |    0.000 cps              |   77.586
> cps
>
> -------------------------+---------------------------+--------------------------
>   Incoming call created  |        0                  |
> 0
>   OutGoing call created  |        0                  |
> 63278
>   Total Call created     |                           |
> 63278
>   Current Call           |        0
> |
>
> -------------------------+---------------------------+--------------------------
>   Counter 5              |        0                  |
> 63201
>
> -------------------------+---------------------------+--------------------------
>   Successful call        |        0                  |
> 63201
>   Failed call            |        0                  |       77
>
>
> And then when I do the "top" command again I see the following
>
>
> Mem:   1022536k total,   675176k used,   347360k free,    30956k buffers
> Swap:  2097148k total,        0k used,  2097148k free,   345944k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 15327 mysql     20   0  333m 183m  10m S    1 18.4  12:29.06 mysqld
> 18643 opensips  20   0  281m  28m  26m S    0  2.9   0:12.51 opensips
> 18644 opensips  20   0  281m  28m  26m S    0  2.9   0:12.26 opensips
> 18647 opensips  20   0  281m  28m  26m S    0  2.9   0:12.42 opensips
> 18646 opensips  20   0  281m  28m  26m S    0  2.9   0:12.34 opensips
> 18648 opensips  20   0  281m  28m  26m S    0  2.9   0:12.41 opensips
> 18649 opensips  20   0  281m  28m  26m S    0  2.9   0:12.27 opensips
> 18650 opensips  20   0  281m  28m  26m S    0  2.9   0:12.32 opensips
> 18651 opensips  20   0  281m  28m  26m S    0  2.9   0:12.28 opensips
> 18645 opensips  20   0  281m  28m  26m S    0  2.8   0:12.35 opensips
> 18652 opensips  20   0  281m  28m  26m S    0  2.8   0:12.32 opensips
> 18654 opensips  20   0  283m  26m  24m S    0  2.7   0:02.51 opensips
>  1084 root      20   0 63012  15m 2788 S    0  1.5   0:00.28
> opensips-mi-pro
>  1096 root      20   0 73296  14m 3128 S    0  1.5   0:00.89
> media-dispatche
> 18642 opensips  20   0  281m 9860 7404 S    0  1.0   0:00.15 opensips
> 18639 opensips  20   0  281m 8360 6096 S    0  0.8   0:00.09 opensips
> 18640 opensips  20   0  283m 4192 1572 S    0  0.4   0:00.15 opensips
> 18656 opensips  20   0  283m 4084 1800 S    0  0.4   0:00.25 opensips
> 18641 opensips  20   0  281m 3448 1144 S    0  0.3   0:00.00 opensips
> 18655 opensips  20   0  281m 3208  940 S    0  0.3   0:00.15 opensips
> 18653 opensips  20   0  281m 2320   88 S    0  0.2   0:01.06 opensips
>
>
>
>  So a lot of the opensips processes have about 2.9% memory.  I wait more
> than 20 minutes to see if the memory would be released but it didn't.
>
> Not sure if this is a bad thing or not.  I could let my SIPP test just keep
> running to see if OpenSIPS crashes from no memory if the memory keeps
> creeping up or I could do a "kill -SIGUSR1 18643" to see what is currently
> using the memory?  Any thoughts or is this not an issue at all?
>
>
>
>
>   On Tue, Apr 5, 2011 at 4:31 AM, Bogdan-Andrei Iancu <bogdan at opensips.org
> > wrote:
>
>> Hi Duane,
>>
>>
>> On 04/05/2011 06:54 AM, duane.larson at gmail.com wrote:
>>
>>> A while back I had posted on here thinking that i might have a memory
>>> leak
>>>
>>> http://opensips-open-sip-server.1449251.n2.nabble.com/Memory-leak-td5942660.html#a5949293
>>>
>>> I've had to fix my SIPP scripts but also I had to change some stuff in my
>>> opensips.cfg file. In my script I commented out all of the times I set an
>>> AVP variable.
>>>
>>> So my question is
>>>
>>> Every time you load an AVP it gets put into memory correct?
>>>
>> yes, in shared memory, to be more specific.
>>
>> So in order for the memory not to get overloaded you need to do
>>> "avp_delete" correct?
>>>
>> not necessarily - you use the function only only if you want to delete the
>> AVPs at some specific point in script. AVPs are transaction/message
>> persistent , and they are automatically deleted when the transaction /
>> message is deleted (AVPs are part of transaction/message)
>>
>> What about the AVPs that are declared in modparam's and that are set in
>>> the script?
>>>
>> those are just names of AVPs, not instances of AVPs
>>
>> How do you make sure those are not overloading memory? What else could
>>> cause my opensips processes to gradually eat up the memory before opensips
>>> just starts erroring out because of no memory?
>>>
>> As said, AVPs cannot cumulate in memory as they are attached to structures
>> (transactions/messages) that are deleted.
>>
>> If you get errors on on running out of memory, please read and follow:
>>    http://www.opensips.org/Resources/DocsTsMem
>>
>> Regards,
>> Bogdan
>>
>>
>> --
>> Bogdan-Andrei Iancu
>> OpenSIPS eBootcamp - 2nd of May 2011
>> OpenSIPS solutions and "know-how"
>>
>>
>
>
> --
> --
> *--*--*--*--*--*
> Duane
> *--*--*--*--*--*
> --
>



-- 
--
*--*--*--*--*--*
Duane
*--*--*--*--*--*
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110405/7e29bb87/attachment-0001.htm>


More information about the Users mailing list