[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