[OpenSIPS-Users] Memory Issues because of AVPs?
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Apr 6 16:10:18 CEST 2011
Duane,
trying to follow what you are saying :) - the mem leak you observe is
for system memory (when you look with top) or is opensips memory
(private or shared) ?
Regards,
Bogdan
On 04/06/2011 06:18 AM, Duane Larson wrote:
> 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
> <mailto: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 <mailto:sip%3A102 at test.com> |
> DIALOG_PUBLISH | 64 | 0 | 1302067600 | 1024 |
> | | | | | |
> | 0 | | | | 0
> | |
> | 642014 | sip:102 at test.com <mailto:sip%3A102 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 <mailto:bogdan at opensips.org>> wrote:
>
> Hi Duane,
>
>
> On 04/05/2011 06:54 AM, duane.larson at gmail.com
> <mailto: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
> *--*--*--*--*--*
> --
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110406/4725d569/attachment-0001.htm>
More information about the Users
mailing list