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
T
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 Bogdan-Andre
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 1/18
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 Developer
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
https://www.ma
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?) from
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 sti
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
https://open
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 i
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
ERROR:core:fm_ma
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, Ams
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 possib
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.
B
gt;>>>>
>>>>>
>>>>>
>>>>> 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 t
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 wo
for sure. The statistics you provided seem like the memory 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!).
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 OS, so
>>>> you are instructing OpenSIPS to allocate much more than your system memory
>>>> right
nder 2GB free, so you have a lot of
>>> 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
>>&g
where. IIRC there are a few
>> processes/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
y need to investigate some of 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>
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 ensu
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:
http
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, "B
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 backwards. I should be more
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 bran
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 t
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] - http://lists.opensips.org/pipermail/users/2018-February/038842.htm
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 t
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 h
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 problem
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 issue[1]. Can
> you pelase te
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]
https://g
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
wrote:
> Hi Team, I've found an issue when I reload regular e
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 gc
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] www.opensips.org/About/Avail
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 op
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 a
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 sometimes
I am using OpenSIPS version 1.6.2-notls with various modules enabled.
The startup command line has the memory option set to "-m 256"
After opensips is running for about 1 week, I start to see errors and
warnings like the following:
Oct 4 08:11:36 SIP01 /sbin/opensips[17153]:
ERROR:snmpstats:inser
Hi Yannick,
That is good - it means we are fixing bugs ;)
Regards,
Bogdan
yannick.leco...@nexcom.fr wrote:
I've moved to 1.6.4 and there is no more leak.
Hi,
I am using opensips 1.6.2.
I have modified the opensips.cfg script and it generates a memory leak.
The memory leak seems to
I've moved to 1.6.4 and there is no more leak.
> Hi,
>
>
>
> I am using opensips 1.6.2.
>
> I have modified the opensips.cfg script and it generates a memory leak.
>
>
>
> The memory leak seems to be on pkmem since when I use the following
> command
> 'opensipsctl fifo get_statistics pkmem: shmem:
Hi,
I am using opensips 1.6.2.
I have modified the opensips.cfg script and it generates a memory leak.
The memory leak seems to be on pkmem since when I use the following command
'opensipsctl fifo get_statistics pkmem: shmem: | grep free', pkmem dicreases
I have followed the documenta
Thanks Anca and Bogdan. Both of you are right in a way. SIPP is, after a
while, leaving a lot of dialogs in "state 3". It could be because I am
using the same server as the SIPP UAS and UAC. I will need to split the
SIPP processes up to see if that changes things.
I am not sure if all the Dial
Hi Duane,
actually, checking the dump you sent, I see no trace of a leak - the pkg
dump shows only script and DB conn mem, while the shm is empty.
So, in your case, you may have a memory overload because because of
runtime issues (but not a leak). If dialogs are not removed by BYEs, I
guess
Hi Duane,
On 01/20/2011 11:22 PM, Duane Larson wrote:
After looking a little more do you think this would cause the memory
issue...
Looks like my SIPP test starts the call, does whatever I want and
sends the BYE, but the dialog is still in the database after the call
has ended between the UA
After looking a little more do you think this would cause the memory
issue...
Looks like my SIPP test starts the call, does whatever I want and sends the
BYE, but the dialog is still in the database after the call has ended
between the UAS and UAC. I am currently using USRLOC db_mode = 2, so I am
I do have some memory stuff in syslog. I have posted the output here
http://paste.ubuntu.com/556285/
On Thu, Jan 20, 2011 at 4:13 AM, Bogdan-Andrei Iancu wrote:
> Hi Duane,
>
> with
>
> mem_log=10
> mem_dump=1
> debug=3
>
> do you see at runtime any logs related to memory ?? (al
Hi Duane,
with
mem_log=10
mem_dump=1
debug=3
do you see at runtime any logs related to memory ?? (alloc, dealloc
logs, no error) . Normally you shouldn't see anyonly when a me dump
is done (at shutdown for example).
Regards,
Bogdan
Duane Larson wrote:
I am trying to st
I am trying to stress test my opensips config with SIPP but was seeing that
after running it for a while I would start getting failed calls and
eventually opensips would die. I recompiled opensips by following
http://www.opensips.org/Resources/DocsTsMem
I also added the following to the config
54 matches
Mail list logo
