The statistics of kamailio pkg and shm show rather steady values across
the period of time.
PKG is like less than 4MB for each process always and SHM stays free at
426MB.
So obviously there is no leak in pkg and shm.
Check the details at the next link for OS memory reports:
-
Just to be clear. The memory is in Kilobytes (kB).
--
*Nuno Miguel Reis* | *Unified Communication** Systems*
M. +351 913907481 | nr...@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
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
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:
-
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 |
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
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 nr...@wavecom.pt wrote:
Hi Juha and all.
I understand that and that is what the RFC says. It seems pua module does
that right. Although something is
Hello all.
Just want to tell you that the problem remains even after the patch Daniel
add to the latest 4.2.
I've sent another email yesterday (partially quoted bellow) to the mailing
list which was already answered by Juha Heinanen in cc regarding an odd
behavior (seems odd to me) i'm seeing.
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
Hello,
I applied the patch, with some adjustments. Now in master, to be
backported to stable branches soon.
Cheers,
Daniel
On 13/01/15 20:16, Nuno Reis wrote:
Hi Kristian and Daniel.
Kristian, hhanks for you feedback and patch.
I'll try your patch here and will let you know the outcome
Hi Kristian and Daniel.
Kristian, hhanks for you feedback and patch.
I'll try your patch here and will let you know the outcome soon.
Thanks again guys.
Cheers,
--
*Nuno Miguel Reis* | *Unified Communication** Systems*
M. +351 913907481 | nr...@wavecom.pt
WAVECOM-Soluções Rádio, S.A.
Cacia
Hello,
thanks for the details and patch. I will try to look at later today.
Cheers,
Daniel
On 13/01/15 08:35, Kristian F. Høgh wrote:
Hi,
I've been hunting a memory error in publish handling the last couple
of days.
The error is on our old but good 3.1.x presence server.
Using
Hi,
I've been hunting a memory error in publish handling the last couple of days.
The error is on our old but good 3.1.x presence server.
Using memory debug, I located the memory leak in modules/presence/hash.c,
function insert_phtable, line 492 (in trunk):
p= (pres_entry_t*)shm_malloc(size);
13 matches
Mail list logo
