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 <[email protected]> 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 [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?
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
