Hi Duane,
For the pua, pua_dialoginfo and the presence part, I advise you to
update your code from svn. Recently there has been a change in them for
exactly this - cleaning up the records faster to avoid memory filling up.
Regards,
--
Anca Vamanu
OpenSIPS Developer
On 04/06/2011 06:21 PM, duane.lar...@gmail.com wrote:
Sorry for the confusion. Orginally when I was testing my opensips
config with the dialoginfo_set() function used in the script I was
running into opensips memory (pk and sh) running out. This is most
likely due to the fact that a ton of records were building up in the
PUA table because opensips was generating pua message because of the
dialoginfo_set() even though I had commented out everything else in my
opensips script that had to do with pua and presence. I am hoping that
when I am done with stress testing and enable all my presence and pua
stuff the dialoginfo_set() functions will work as normal and not place
a ton of records in the pua table (something I will need to verify
later on).
I think where I was getting confused was that when I did the top
command I would see that my opensips processes were building up memory
under the %MEM column and that number under %MEM was never decreasing
after I waited 20 minutes. Yet last night after doing more research
via the mailing list I ran across the command
opensipsctl fifo get_statistics pkmem: shmem:
When I look at the info from that commands output I see that SHMEM
does get memory back instead of just steadily running out. I also see
that with PKMEM all my processes are using about 1M of memory with 3M
left over and that extra free memory doesn't get touched. So that
leads me to believe that my opensips processes have also stabilized
and aren't just gobbling up memory until it runs out. So even though
the TOP command appears to show that the opensips processes aren't
releasing that %MEM I can see with the opensipsctl fifo get_statistics
command that pkmem and shmem isn't growing and being overloaded.
Does that make more since? Everything for now appears to be good. I
can run my SIPP test for a very long time and OpenSIPS doesn't bomb
out on me with memory issues.
On Apr 6, 2011 9:10am, Bogdan-Andrei Iancu <bog...@opensips.org> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
> 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.lar...@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:1...@test.com
>
> | DIALOG_PUBLISH | 64 | 0 | 1302067600 | 1024
>
> | | | | | |
>
> | | 0 | | |
>
> | 0 | |
>
>
> | 642014 | sip:1...@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?
>
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
