11 Feb
2015
11 Feb
'15
5:26 a.m.
Hi Daniel.
Thank you for your suggestion and feedback on this.
I've tried that already and here's what I've found after 15h on a running
kamailio:
All records in pua and presentity DB tables are gone by the end of the day,
so the expire time seems to be working.
I still see system memory growing and not being released again.
You can find attached (tar.gz) various dumps of pkgstats and shmem usage.
The number after the 'underscore' in file names corresponds to system
memory allocation in kamailio at the various timestamps. The earlier
timestamp corresponds to minute 1.
So I started with 638632kb system mem allocation and I'm now with 1086548kb
being used after 15 hours.
I'll continue to investigate the issue but if you have any other
suggestions on how to tackle this, I'm of course available to test those.
Looking forward to hear from you.
Best Regards,
--
*Nuno Miguel Reis* | *Unified Communication** Systems*
M. +351 913907481 | nreis(a)wavecom.pt
WAVECOM-Soluções Rádio, S.A.
Cacia Park | Rua do Progresso, Lote 15
3800-639 AVEIRO | Portugal
T. +351 309 700 225 | F. +351 234 919 191
*GPS
<http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88>
| www.wavecom.pt <http://www.wavecom.pt/>** <http://www.wavecom.pt/>*
[image: Description: Description: WavecomSignature]
<http://www.wavecom.pt/pt/wavecom/premios.php>
[image: Publicity] <http://www.wavecom.pt/pt/mail_eventos.php>
On Mon, Feb 9, 2015 at 5:05 PM, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
can you check the expires column in presentity table. The issue might be
accumulation of too many dialog-info documents, due to large expires
interval, taken from the default lifetime of the dialog. You can change
that with:
-
http://kamailio.org/docs/modules/4.2.x/modules/pua_dialoginfo.html#idp25769…
Cheers,
Daniel
On 30/01/15 16:43, Nuno Reis wrote:
Hi Daniel.
Thanks for answering me back. I'll follow the exact procedures from
here: http://www.kamailio.org/wiki/tutorials/troubleshooting/memory and
will let you know about my exact finding soon.
Cheers,
--
*Nuno Miguel Reis* | *Unified Communication** Systems*
M. +351 913907481 | nreis(a)wavecom.pt
WAVECOM-Soluções Rádio, S.A.
Cacia Park | Rua do Progresso, Lote 15
3800-639 AVEIRO | Portugal
T. +351 309 700 225 | F. +351 234 919 191
*GPS
<http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88>
| www.wavecom.pt <http://www.wavecom.pt/>** <http://www.wavecom.pt/>*
[image: Description: Description: WavecomSignature]
<http://www.wavecom.pt/pt/wavecom/premios.php>
[image: Publicity] <http://www.wavecom.pt/pt/mail_eventos.php>
On Fri, Jan 30, 2015 at 5:23 AM, Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
Hello,
which memory is increasing? shared or private memory? or is system
memory?
Cheers,
Daniel
On Fri, Jan 30, 2015 at 4:24 AM, Nuno Reis <nreis(a)wavecom.pt> wrote:
--
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
Hi Juha and all.
I understand that and that is what the RFC says. It seems pua module
does that right. Although something is clearly not right in my production
environment because kamailio memory consumption still grows pretty fast.
Kamailio memory usage starts in ~500MB and after ~24H kamailio is using
~3GB. If I disable kamailio from listening on the localhost(127.0.0.1)
where pua is generating the SIP Publishes kamailio just keeps around the
~500MB all the time.
This is a small production environment with 70 extensions with Yealink
phones.
Any ideas on how to chase down this memory leak? Should I open a git
issue for this one?
--
*Nuno Miguel Reis* | *Unified Communication** Systems*
M. +351 913907481 | nreis(a)wavecom.pt
WAVECOM-Soluções Rádio, S.A.
Cacia Park | Rua do Progresso, Lote 15
3800-639 AVEIRO | Portugal
T. +351 309 700 225 | F. +351 234 919 191
*GPS
<http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88>
| www.wavecom.pt <http://www.wavecom.pt/>** <http://www.wavecom.pt/>*
[image: Description: Description: WavecomSignature]
<http://www.wavecom.pt/pt/wavecom/premios.php>
[image: Publicity] <http://www.wavecom.pt/pt/mail_eventos.php>
On Wed, Jan 21, 2015 at 8:45 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/micond
<http://www.linkedin.com/in/miconda>
Nuno Reis writes:
> Here my publisher is Kamailio itself. Can someone elaborate a bit
more on
> this issue and maybe we can get to bottom of it?
when your application issues initial publish request, it does so without
SIP-If-Match header. 200 ok from presence server then contains an etag
in SIP-ETag header. when your application refreshes the publish, it must
place this etag in SIP-If-Match header to prevent presence server from
creating a new publication.
for subscribes, your application must place in re-subscribe the
same event header id param as the previous one had in order for the
presence server to know that subscribe was not a new subscription.
-- juha
