[OpenSIPS-Users] Memory Issues because of AVPs?
duane.larson at gmail.com
duane.larson at gmail.com
Wed Apr 6 17:21:21 CEST 2011
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 <bogdan at 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.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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110406/d6042d67/attachment-0001.htm>
More information about the Users
mailing list