That's EOL for quite some time :(
Either consider more pkg mem (to cope with fragmentation) , either an
upgrade to 3.4
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 03.04.2024 17:34, Johan De Clercq wrote:
A
What OpenSIPS version is there ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 03.04.2024 17:04, Johan De Clercq wrote:
In addtion, I have 24 children, so can I increase in some way only the
process that handles
In addtion, I have 24 children, so can I increase in some way only the
process that handles the fifo requests ?
Op wo 3 apr 2024 om 15:33 schreef Johan De Clercq :
> Hi,
>
> A client has a very big dynamic routing rule set. (dr_rules >= 2.1 gb ).
> When reloading the db in opensips (dr_reload),
Hi,
A client has a very big dynamic routing rule set. (dr_rules >= 2.1 gb ).
When reloading the db in opensips (dr_reload), I see below error in the log
ERROR:core:fm_malloc: not enough free pkg memory (268008864 bytes left),
please increase the "-M" command line parameter!
the -M parameter is
I will rephrase my question maybe someone has any ideas If I check memory
usage with pmap for highest using opensips process:
total kB 10774396 4579784 4564420
And this is the same as what top shows, around 4.5G memory usage.
If I use opensips-cli -x mi mem_pkg_dump for the same PID: heap
Hi List,
I am trying to understand memory reports and find a possible memory leak. I
have: -a Q_MALLOC_DBG -m 2048 -M 4096 and memdump=1, my system has 32G ram,
8 workers.
When opensips starts I have 25G free memory. after 10days, I have only 12G
free memory, top showing one of opensips processes
Hi All,
*(originally sent back in December with an image embedded which possibly
got the mail rejected!)*
I'm experiencing a memory leak on an OpenSIPs 3.2.10 instance (was 3.2.4,
upgrades to 3.2.9 and 3.2.10 did not resolve) which is acting as a WebRTC
proxy - this is running on AlmaLinux 9.0
Better don't :), as we never explored all the possible side effects of
such combination of versions
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS eBootcamp 2021
https://opensips.org/training/OpenSIPS_eBootcamp_2021/
On 1/19/22
That's a given the question is can it mess up the active server if the
passive one was updated already? I'm not planning on leaving it like that I
just like to do the upgrades slowly, one at a time and test it and only
then to upgrade the second one.
Scott
On Wed, Jan 19, 2022, 09:26
Hi Schneur,
It is strongly recommend that all OpenSIPS nodes in a cluster to have
the same version.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS eBootcamp 2021
https://opensips.org/training/OpenSIPS_eBootcamp_2021/
On
Hi Schneur,
I suspect that the leaking mk_proxy is related to the changing of the
RURI in local route. Let me test your snippet. BTW, is that the whole
processing you do in local route? is the $rd (from LB) a FQDN or
straight IP ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and
Hi Bogdan
I think I found the issue, I recently added these lines of code,
because of a probing issue I was having, I just searched from my
previous tickets and I see that you have warned me about the
implications but for some reason I never read the message.
Here is the old ticket
Hi Schneur,
Yeah, comparing the last 2 dumps, I see 9615 (prev 704) chunks
accumulating from mk_proxy() + hostent_cpy(). But it is a tough one to
identify what is triggering the leak.
You mentioned this happens only from the timer process, right ? do you
do anything (pinging?, probing?)
Here is a newer dump
https://pastebin.com/2CTihBVD
On Fri, Dec 10, 2021 at 2:16 PM Schneur Rosenberg
wrote:
>
> Hi Bogdan,
>
> I did it on a backup server, its also leaking memory but at a slower
> pace, I'm attaching the logs when running kill -SIGUSR1 on the pid
> that's growing in size, it
Hi Schneur,
Just follow the
https://www.opensips.org/Documentation/TroubleShooting-OutOfMem and
provide the dump. This is the only way to investigate this.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS eBootcamp 2021
I just noticed that process 88 runs the timer handler, perhaps this
might shed light on whats going on.
opensipsctl fifo ps
Process:: ID=88 PID=5327 Type=Timer handler
On Wed, Dec 8, 2021 at 10:55 AM Schneur Rosenberg
wrote:
>
> Now a few hours later this is what I'm getting
> Dec 8 09:50:13
Now a few hours later this is what I'm getting
Dec 8 09:50:13 /sbin/opensips[21699]: ERROR:nathelper:nh_timer: out
of pkg memory
Dec 8 09:50:16 /sbin/opensips[21699]: WARNING:core:fm_malloc: not
enough continuous free pkg memory (3024 bytes left, need 5128),
attempting defragmentation... please
Hi, lately I'm getting these errors in my logs.
ERROR:core:fm_malloc: not enough free pkg memory (1792 bytes left,
need 2184), please increase the "-M" command line para
meter!
CRITICAL:core:hostent_cpy: pkg memory allocation failure
ERROR:nathelper:nh_timer: out of pkg memory
Hi,
See https://opensips.org/Documentation/TroubleShooting-OutOfMem
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/15/20 12:40 AM, Saint Michael wrote:
I see hundreds of messages like this
how I raise the memory? My box has
>
> I see hundreds of messages like this
how I raise the memory? My box has unlimited memory, but opensips does not
use it.
I changed the parameters inside the file opensips.service, but it did not
changed the memory allocated.
Apr 14 21:06:13 [117509] ERROR:core:fm_malloc: not enough free shm
Resolution here: it seems the recently added {ip.matches} transformation was
leaking pkg memory. Fixed on latest 3.0 and master [1].
Enjoy,
[1]: https://github.com/OpenSIPS/opensips/commit/1c4fa53f2fab6
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com
OpenSIPS Summit,
Hi Liviu,
Thanks for coming back to me.
I am continuing to have memory problems on these servers however I have
stemmed the flow as per my previous emails here. I am still in an
uncomfortable position where the systems need to be restarted weekly so I'd
like to get this resolved as soon as
Hi Callum,
Sorry for the late follow-up: did you make any progress with your leak?
If not, could you prepare a minimal opensips.cfg that exposes the
problem? A quick
code review did not show any obvious leaks, so I suspect there is something
about your specific script that I am overlooking.
>>> You are setting your package memory size to 4G, so that will allocate
>>>>> 4G memory for every package (process) that loads and then 2G for shared
>>>>> memory. That will use up all the memory on your machine extremely quickly
>>>>> for s
Hi All,
I wanted to follow up on a recent issue I experienced to understand if
it was due to user error or a bug that needs to be patched.
The issue was traced back to a simple function call in the permissions module:
check_source_address(0, $avp(address_desc))
Nearly every request processed
y increase is
>>>> consistent with higher traffic levels on the second reading. You can see
>>>> in your case that all of your “pkmem” processes have an extremely high
>>>> amount of free memory (~3GB!). But that memory is still allocated from the
>>>&g
an extremely high amount
>>>> of free memory (~3GB!). But that memory is still allocated from the OS, so
>>>> you are instructing OpenSIPS to allocate much more than your system memory
>>>> right at startup.
>>>>
>>>>
>>>>
>&g
gt; headroom there too. Since OpenSIPS pre-allocates, the amount of memory
>>> being used by the system overall should be fairly steady; if it is
>>> continuously increasing that implies a leak somewhere. IIRC there are a few
>>> processes/modules/commands in OpenSIPS or
sses/modules/commands in OpenSIPS or libraries it uses that do
>> allocate memory directly from the system and not from OpenSIPS’ pool. You
>> may need to investigate some of those to find out where your memory is
>> going, or look at other processes/daemons you have running t
those to find out where your memory is
> going, or look at other processes/daemons you have running that could be
> using that memory.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users on behalf of Callum Guy <
> callum@x-on.co.uk>
> *Reply-To: *OpenSIPS users m
29, 2019 at 10:57 AM
To: OpenSIPS users mailling list
Subject: [OpenSIPS-Users] Memory Leak - runtime flags?
Hi All,
I have recently deployed a new registrar and have been seeing a gradual
increase in the memory footprint - enough that I'm having to expand the RAM
(its virtualised) to ensure
Hi All,
I have recently deployed a new registrar and have been seeing a gradual
increase in the memory footprint - enough that I'm having to expand the RAM
(its virtualised) to ensure it doesn't run out.
You can see a diff of the statistics collected last night at 11pm and today
at 3pm here:
No worrkes, I am glad it all worked out :D!
Cheers,
Răzvan
On 05/17/2018 04:59 AM, Ben Newlin wrote:
Razvan,
One more time with an apology!
I was also reading my statistics wrong. This patch does fix the memory leak.
Sorry for all the emails.
Thanks,
Ben Newlin
On 5/16/18, 5:52 PM,
Razvan,
One more time with an apology!
I was also reading my statistics wrong. This patch does fix the memory leak.
Sorry for all the emails.
Thanks,
Ben Newlin
On 5/16/18, 5:52 PM, "Ben Newlin" wrote:
Razvan,
I apologize, I was reading the diff
Razvan,
I apologize, I was reading the diff backwards. I should be more careful. Your
fix from that commit does in fact exist in 2.3 latest.
However, my results are unchanged. I still see a significant memory leak when
using the sip_trace function.
Thanks,
Ben Newlin
On 5/16/18, 5:49 PM,
Razvan,
I think you are referring to this commit [1]?
I can see that this was committed 27 days ago, but when I pull the latest 2.3
branch, the change from this commit is not there. It would appear a subsequent
commit has removed this change.
The memory leak still exists on the latest 2.3
Hi, Ben!
This has actually been solved in the latest 2.3 code a few weeks back,
but the fix did not "catch" the 2.3.3 release. So if you can, pull the
latest 2.3 sources and test again.
Best regards,
Răzvan
On 05/15/2018 06:12 PM, Ben Newlin wrote:
Hi,
I was actually able to isolate this
Hi,
I was actually able to isolate this to the siptrace module and then I
remembered this thread [1] from February. Was this issue ever resolved? It
looks like it was reported in 2.3.2, but we are still seeing it in 2.3.3.
[1] -
Hi,
We have recently upgraded to OpenSIPs 2.3.3 and after deploying to our
production environment we have found a significant memory leak. The leak is
being reported by OpenSIPS’ statistics only; the used memory of the machine
itself is not increasing.
I believe I have been able to reproduce
Nevermind. Seems like -m is 32MB and -M 2MB by default.
From: Users <users-boun...@lists.opensips.org> on behalf of Matt Hamilton
<mistral9...@hotmail.com>
Sent: Thursday, December 22, 2016 3:48:11 PM
To: Opensips Users
Subject: [OpenSIPS-Users] me
We are running 1.11.5 (TLS) and running into memory issues (not enough free
memory). I'm aware of the memory options (-m and -M). What are their default
values?
Is it possible to query a running Opensips instance to find out what these
values are set to (to confirm once I change them)?
We
Denis, please try this and see if the PRACK gets routed correctly (and
you should also get rid of the warnings and memory issues).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 21.11.2016 13:22, Denis wrote:
Re: [OpenSIPS-Users] Memory free
ops on it.
If I send you a small patch (to allow PRACK inside dialog) could you test it ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 21.11.2016 10:24, Denis wrote:
Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan!
Yes, the ngrep shows that PR
rei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 21.11.2016 10:24, Denis wrote:
Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan!
Yes, the ngrep shows that PRACK has been received, but not sent to
dest SIP UA.
The question is, why "is looping big time
how often the warning with bogus state
appears. Check the routing for PRACK.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.11.2016 11:43, Denis wrote:
Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan!
The log you can find here
https://clo
-solutions.com
On 18.11.2016 11:43, Denis wrote:
Re: [OpenSIPS-Users] Memory free problem Hello, Bogdan!
The log you can find here
https://cloud.mail.ru/public/84c1/Fw9VGe2J9
mailto:denis7...@mail.ru
Hi Denis,
I do not think they are related. The warnings report some traffic
anomalies - a PRACK
Hello, Bogdan!
The log you can find here
https://cloud.mail.ru/public/84c1/Fw9VGe2J9
mailto:denis7...@mail.ru
Hi Denis,
I do not think they are related. The warnings report some traffic anomalies - a
PRACK request for a confirmed dialog (with 200 OK).
On the memory part, if the log is
Hello!
Today i have a temporary problem with out of free memory (about 4 minutes).
Unfortunately, i noticed the problem when everything became fine, so i didn`t
make standard procedure of detecting problems with memory which has been
described in documentation.
In syslog i see such sequence of
Hi John,
Please see http://www.opensips.org/Documentation/TroubleShooting-OutOfMem
Let me know if you additional help .
Best Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 03.08.2016 16:18, John Quick wrote:
One of my OpenSIPS Proxy servers
One of my OpenSIPS Proxy servers has a memory leak that is bad enough to
require the service to be restarted once a week.
It was running version 2.1.1 and I just upgraded it this morning to v.2.1.4,
but the memory leak is still happening.
What are the best next steps to help track down the
Hi Dragomir,
Please compile with F_MALLOC / QM_MALLOC / HP_MALLOC with DBG_MALLOC -
this will generate (when sending SIGUSR1) a memory dump. See more on:
http://www.opensips.org/Documentation/TroubleShooting-OutOfMem
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
On 05/02/2016 05:08 PM, Dragomir Haralambiev wrote:
I have registration activity with Radius asin
So, why do you expect fragmentation from time to time as the OpenSIPS
memory manager allocates and frees SHM blocks?
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street
I have registration activity with Radius asin
2016-05-02 23:44 GMT+03:00 Alex Balashov :
> On 05/02/2016 04:22 PM, Dragomir Haralambiev wrote:
>
> Opensips has not routed any calls.
>>
>
> Has it done anything else, including passive registration activity or any
>
Hi Dragomir,
And there is no activity at all on that opensips ? nothing at all ? no
traffic ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 02.05.2016 23:22, Dragomir Haralambiev wrote:
Hello,
I have monitoring memory segments of Opensips
On 05/02/2016 04:44 PM, Alex Balashov wrote:
On 05/02/2016 04:22 PM, Dragomir Haralambiev wrote:
Opensips has not routed any calls.
Has it done anything else, including passive registration activity or
any periodic database-bound synchronisation tasks?
Also, what about passively deflecting
On 05/02/2016 04:22 PM, Dragomir Haralambiev wrote:
Opensips has not routed any calls.
Has it done anything else, including passive registration activity or
any periodic database-bound synchronisation tasks?
--
Alex Balashov | Principal | Evariste Systems LLC
1447 Peachtree Street NE,
Hello,
I have monitoring memory segments of Opensips 2.2.
For the past 4 days memory fragment has increased from 940 to 1295.
Opensips has not routed any calls.
Is this normaly?
Regards,
Dragomir
___
Users mailing list
Users@lists.opensips.org
Hi Răzvan,
I tested the fix, it's working fine now
Thanks!
On Mon, Sep 14, 2015 at 4:52 AM, Răzvan Crainea wrote:
> Hi, Federico!
>
> Nice catch! Indeed, there seems to be a pkg memory leak during reload.
> I committed a fix on the master branch that shoul fix this
Hi, Federico!
Nice catch! Indeed, there seems to be a pkg memory leak during reload.
I committed a fix on the master branch that shoul fix this issue[1]. Can
you pelase test and let me know everything is ok this time, so I can
backport the fix to the other branches (2.1, 1.11).
[1]
Hello,
in function load_pcres in regex_mod.c, I see that when you allocate memory
to read regex groups, the loop goes up to the max_groups parameter (
http://www.opensips.org/html/docs/modules/1.11.x/regex.html#id249240) :
for (i=0; i
Hi Team, I've found an issue when I reload regular expresion file for
opensips 1.11.5.
After executing a few "opensipsctl fifo regex_reload", the fifo process
runs out of pkmem. This is a small loop where I do a regex_reload and then
I print the pkmem for MI FIFO processs:
root@toro:~# sudo -u
Hi Vlad,
As Liviu replied, it is extremely likely that OpenSIPS 1.9.2 does not have
memory leak. All is because I did not fully understand the Linux memory
management. After doing the stress tests for several days, OpenSIPS remains
to work normally. Thanks for your comment.
Best wishes,
Chen-Che
Hello,
Is the leak you are reporting happening in shared memory, or pkg ? Your
logs contain just PKG memory dump ?
OpenSIPS 1.9 is no longer supported ( see [1] ), so I would advise you
to update to the latest OpenSIPS 1.11 ( latest minor release is 1.11.4 )
[1]
Hi Chen-Che,
It is best to start off with a quick tutorial. Here you can learn how
the Linux kernel manages your RAM (~ 2 minutes): [1]
I've inspected your OpenSIPS memory maps, and they both look OK. For the
record, OpenSIPS will _never_ use more RAM than you give it at startup:
total
Hi all,
I'm using OpenSIPS version 1.9.2 to set up a SIP outbound proxy and two
internal SIP servers in my testing environment.
All SIP requests and responses follow the same following routes.
SIP client -- SIP outbound proxy -- SIP server -- SIP outbound proxy --
SIP clients
With some stress
Hi,
I have one opensips server deployed on Amazon cloud.
I am using AWS health monitoring service which pings opensips intermittently.
(TCP port 5060)
The following error showed up in the log after a few days:
ERROR:core:tcpconn_new: No more SHM for send chunks pointers
Tried to know more
Hello Ahsan,
Thank you for the valuable input. I CC'ed here Ovidiu - he is the author
of the QoS module and maybe he can help here.
I see the crash is reproducible - can you do it in a non-production env
where we can enable some more debugging ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS
Hi,
I have not been able to reproduce this issue in my dev environment (replica
of production), because the only traffic on that server is mine.
Where as on production environment, its occurrence is totally random, it
may not crash in a month, or would crash twice a day.
--
Ahsan Hasan
On Thu,
I just saw now that this is related to the qos module. I will take a look
and get back to you all.
-ovidiu
On Feb 13, 2014 11:17 PM, Ahsan Hasan ahsanhasanja...@gmail.com wrote:
Hi,
I have not been able to reproduce this issue in my dev environment
(replica of production), because the only
In the meantime, I have disabled the qos module from my production
environment. Lets see if it crashes again.
--
Ahsan Hasan
On Fri, Feb 14, 2014 at 9:34 AM, Ovidiu Sas o...@voipembedded.com wrote:
I just saw now that this is related to the qos module. I will take a look
and get back to you
Hello,
Two things:
1) be sure you have the latest 1.9.1 code (GIT or tar balls)
2) post the actual backtrace (from the core file), please
Thanks and regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11.02.2014 06:25, Ahsan Hasan wrote:
So it
The Opensips version I am using is 1.9.1 compiled from src tar. The output
of opensips -V is below:
===
version: opensips 1.9.1-tls (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST,
SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC,
So it crashed again today. Here is the log
Feb 10 18:26:24 RTSIP rtsip-service[10443]: CRITICAL:core:qm_free: freeing
already freed pointer, first free: parser/sdp/sdp.c:
free_cloned_sdp_stream(874) - aborting
Feb 10 18:26:25 RTSIP rtsip-service[10464]: CRITICAL:core:receive_fd: EOF
on 25
On
We are using opensips-1.9.1 and it is crashing randomly every other week,
the core dumps generated are always related to memory leakage. The last
four core dumps are
Program terminated with signal 11, Segmentation fault.
#0 0x7f4c12e20c77 in write_dialog_profiles (links=0x7f4bff03d7f0) at
Hi, Ahsan!
Can you please enable the the memory debugging (DBG_QM_MALLOC flag in
menuconfig)? You can follow this tutorial[1].
[1] http://www.opensips.org/Documentation/TroubleShooting-OutOfMem
Best regards,
Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
On
Hello,
Today after months of normal operation I have experienced an issue with
OpenSIPS (running packaged LTS opensips-1.8.3-1.el6.x86_64).
OpenSIPS ceased accepting requests and I found the following error log
entries in the log file:
Dec 11 05:35:34 localhost /usr/sbin/opensips[5276]:
Hello Chen-Che,
So, following the BYE handling, do you see a difference between the
processed_dialogs and active_dialogs ? The diff should give you the
number of terminated dialogs - just to be 100% sure your config ends the
dialogs.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and
Hi Bogdan-Andrei,
As you suggest, I call match_dialog() at the outbound proxy when receiving
the BYEs.
Indeed, the match_dialog() returns true. However, the number of
active_dialogs still
increases and thus more memory is eaten by OpenSIPS. I also find that memory
consumption
issue occur when
Hi Bogdan-Andrei,
I agree with you. The call flow in my setting is as follows.
For request, caller--outbound proxy--proxy server--outbound
proxy--callee
For reply, caller--outbound proxy--proxy server--outbound proxy--callee
Is is possible that a message reaching the same outbound proxy twice
Hello Chen-Che,
It is not about the retransmission, it simply look like your OpenSIPS
does not see the BYE requests:
- is your scenario hanging up the calls ?
- do you do record-route/loose-route in script ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
Hi Bogdan-Andrei,
Regarding your questions,
1. The OpenSIPS at the outbound proxy sees and forwards BYEs successfully
for each call.
2. No record-route/loose-route are called at the outbound proxy.
So the root cause may be the lack of using record_route()/loose_route()?
Best regards,
Chen-Che
If BYEs are going through your server and you do not use record-route,
you should call match_dialog() function for the BYEs, to be sure they
are matched against the existing dialogs.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 05/24/2013
Well, this indicate that you have a bug in your test call flows - the
BYE ending the calls should also end the dialogs - there is no need for
them to expire.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 05/23/2013 06:46 AM, microx wrote:
Hi
Hi Bogdan-Andrei,
When you get the memory error, could you please do : opensipsctl fifo
get_statistics all and send me the output (off list) please?
When about 10,000 calls, 10kcalls.log
http://opensips-open-sip-server.1449251.n2.nabble.com/file/n7586442/10kcalls.log
.
When about 20,000
Hi Chen-Che,
Looking at the stats:
at 10K:
dialog:active_dialogs = 21219
dialog:early_dialogs = 1
at 20K:
dialog:active_dialogs = 40473
dialog:early_dialogs = 1
As you can see, your active dialogs keep accumulating and consuming
memory - this is why you run out of shared mem.
Hi Bogdan-Andrei,
With SIPp keeps creating and terminating dialogs round after round, the only
things at the outbound proxy I know are
1) each SIP process occupies more and more memory.
2) opensipsctl fifo get_statistics shmem: shows the shmem:used_size and
shmem:real_used_size both keep
Hello ,
When you get the memory error, could you please do : opensipsctl fifo
get_statistics all and send me the output (off list) please?
Also, at step 4) , by stop, you mean you shutdown OpenSIPS or you stop
the sipp load but OpenSIPS still runs ?
Going back to my request on memory debugging,
Hi,
I do not see any Memory status (shm): in your logs - that is the part
for dumping the shared memory (which you are suspecting of leaking).
There are only logs for the pkg (private, per process) memory.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
Hi Bogdan-Andrei,
Please refer to the log
OpenSIP_outbound_memory.log
http://opensips-open-sip-server.1449251.n2.nabble.com/file/n7586368/OpenSIP_outbound_memory.log
Many thanks for your help.
Best regards,
Chen-Che
--
View this message in context:
Hello Chen-Che,
Sorry for delay :(..unfortunately the links expired - could you repost ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 05/13/2013 11:53 AM, microx wrote:
Hi Bogdan-Andrei,
Will there be any update on this issue? Many thanks
Hi Bogdan-Andrei,
Will there be any update on this issue? Many thanks for your help.
Best regards,
Chen-Che
--
View this message in context:
http://opensips-open-sip-server.1449251.n2.nabble.com/memory-consumed-by-t-relay-tp7586016p7586291.html
Sent from the OpenSIPS - Users mailing list
Hi Chen-Che,
Using 512 M for 500 ongoing transactions should be fine...
Have you tried to compile in the memory debugger to check for leaks (see
the link I sent you -
http://www.opensips.org/Documentation/TroubleShooting-OutOfMem).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and
Hello Chen-Che,
A SIP transaction is a requests plus all its replied (provisional and
final) - the TM module automatically frees all transactions when they
complete (got a final reply or they timeout).
Via statistics you can see how many ongoing transactions you have in
memory opensipsctl
Hi all,
In my environment, I have an outbound proxy and two internal SIP proxy
servers. The outbound proxy listens on two interfaces where one is
(61.60.x.x) for communication with outside UAs and the other is
(192.168.x.x) for communication with internal SIP server. When the outbound
proxy
Hi,
I think that there is a memory leak with TLS.
I have experienced it in my calls stress test, but it is possible to reproduce
it easily with sipp with a simple scenario:
you have only to send REGISTERs in multi socket mode (-t ln).
With this test I can observe the internal memory that
Hello,
In such heavy traffic conditions, OpenSIPS needs more shared memory. Set
a higher value by passing the -m parameter at OpenSIPS startup. For
example, for 512 Mb of shared mem, start opensips with
./opensips -m 512
Regards,
Vlad Paiu
OpenSIPS Developer
Hi,
I'm trying to make calls at 650 calls per sec through opensips LB. I
Observe that after 640 CPS opensips throws the below mentioned errors
fm_malloc: Not enough free memory, will atempt defragmenation
ERROR:tm:new_t: out of mem
___
Users mailing
Hello Vlad,
I updated my OpenSIPS 1.6.2 version. At the moment, the problem did not
occur again.
I hope that the problem has been resolved.
Thanks for the suggestion!
Happy new year!
Cheers!
On 30 December 2011 14:55, Vlad Paiu vladp...@opensips.org wrote:
Hello,
Seems you have
Hello,
Seems you have encountered a memory leak. Might have been fixed in more
recent OpenSIPS releases, but if upgrading is not an option for you,
please follow the tutorial at
http://www.opensips.org/Resources/DocsTsMem and attach on pastebin the
output of the memory dump that OpenSIPS
Hello Guys,
Someone know this error ?
I'm using opensips 1.6.1 with rtpproxy 1.2.1 and Centos 6.0.
Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27117]:
ERROR:sl:sl_send_reply_helper: response building failed
Dec 28 14:01:09 veoscol /usr/local/sbin/opensips[27116]:
ERROR:core:do_action:
1 - 100 of 141 matches
Mail list logo