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 <[email protected]> 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:[email protected] | DIALOG_PUBLISH | 64 | 0 | > 1302067600 | 1024 | | | | | > | | | 0 | | | | > 0 | | > | 642014 | sip:[email protected] | 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 <[email protected] > > wrote: > >> Hi Duane, >> >> >> On 04/05/2011 06:54 AM, [email protected] 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
