On Tuesday 24 January 2012, laura testi wrote:
> we are using the XMPP gateway modules:
> • PUA
> • PUA_XMPP
> • XMPP
> The behavior is ok but since the modules are started, the memory usage
> is getting increased and now also the swap memory area is used.
> I send to you the following information:
Hello Laura,
so kamailio uses that much memory that your machine runs out of memory? This
sounds like a shared memory issue to me. Can you have a look to the shm_mem as
well?
> 1. Numer of records from PUA and xmpp_presentity tables, they are quite
> stable:
>
> SQL> select count(*) from pua;
>
> COUNT(*)
> ----------
> 10218
>
> SQL> select count(*) from xmpp_presentity;
>
> COUNT(*)
> ----------
> 754
>
This output is in PKG mem, but it looks indeed a bit suspicious. Have you
looked in to the respective code for this module, presence: utils_func.h and
uandd_to_uri?
> 2. list of PKG fragments with gdb :
>
> $1 = {size = 40, u = {nxt_free = 0x0, is_free = 0}, file =
> 0x2b657aa12c00 "presence: utils_func.h", func = 0x2b657aa1aed0
> "uandd_to_uri", line = 66,
> check = 4042322160}
> [..]
> $17 = {size = 40, u = {nxt_free = 0x0, is_free = 0}, file =
> 0x2b657aa12c00 "presence: utils_func.h", func = 0x2b657aa1aed0
> "uandd_to_uri", line = 66,
> check = 4042322160}………….
>
> 3. Output of sercmd cfg.set_now_int core mem_dump_pkg :
>
> ……………….. 10969. N address=0xb1b320 frag=0xb1b2f0 size=104 used=1
> qm_status: alloc'd from presence: utils_func.h: uandd_to_uri(66)
> qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed
> qm_status: 10970. N address=0xb1b3e8 frag=0xb1b3b8 size=32 used=1
> qm_status: alloc'd from presence: utils_func.h: uandd_to_uri(66)
> qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed
> qm_status: 10971. N address=0xb1b468 frag=0xb1b438 size=32 used=1
> qm_status: alloc'd from presence: utils_func.h: uandd_to_uri(66)
> qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed
> qm_status: dumping free list stats :
> qm_status: hash= 1. fragments no.: 4, unused: 0
> bucket size: 8 - 8 (first 8)
> qm_status: hash= 2. fragments no.: 8, unused: 0
> bucket size: 16 - 16 (first 16)
> qm_status: hash= 3. fragments no.: 6, unused: 0
> bucket size: 24 - 24 (first 24)
> qm_status: hash= 4. fragments no.: 1, unused: 0
> bucket size: 32 - 32 (first 32)
> qm_status: hash= 6. fragments no.: 3, unused: 0
> bucket size: 48 - 48 (first 48)
> qm_status: hash= 8. fragments no.: 8, unused: 0
> bucket size: 64 - 64 (first 64)
> qm_status: hash= 9. fragments no.: 6, unused: 0
> bucket size: 72 - 72 (first 72)
> qm_status: hash= 12. fragments no.: 5, unused: 0
> bucket size: 96 - 96 (first 96)
> qm_status: hash= 14. fragments no.: 6, unused: 0
> bucket size: 112 - 112 (first 112)
> qm_status: hash= 17. fragments no.: 32, unused: 0
> bucket size: 136 - 136 (first 136)
> qm_status: hash= 19. fragments no.: 1, unused: 0
> bucket size: 152 - 152 (first 152)
> qm_status: hash= 21. fragments no.: 1, unused: 0
> bucket size: 168 - 168 (first 168)
> qm_status: hash= 29. fragments no.: 1, unused: 0
> bucket size: 232 - 232 (first 232)
> qm_status: hash= 31. fragments no.: 2, unused: 0
> bucket size: 248 - 248 (first 248)
> qm_status: hash= 33. fragments no.: 2, unused: 0
> bucket size: 264 - 264 (first 264)
> qm_status: hash= 36. fragments no.: 1, unused: 0
> bucket size: 288 - 288 (first 288)
> qm_status: hash= 57. fragments no.: 1, unused: 0
> bucket size: 456 - 456 (first 456)
> qm_status: hash= 60. fragments no.: 1, unused: 0
> bucket size: 480 - 480 (first 480)
> qm_status: hash= 76. fragments no.: 709, unused: 0
> bucket size: 608 - 608 (first 608)
> qm_status: hash= 88. fragments no.: 1, unused: 0
> bucket size: 704 - 704 (first 704)
> qm_status: hash= 116. fragments no.: 1, unused: 0
> bucket size: 928 - 928 (first 928)
> qm_status: hash= 145. fragments no.: 1, unused: 0
> bucket size: 1160 - 1160 (first 1160)
> qm_status: hash= 216. fragments no.: 2, unused: 0
> bucket size: 1728 - 1728 (first 1728)
> qm_status: hash= 2049. fragments no.: 1, unused: 0
> bucket size: 16384 - 32768 (first 22032)
> qm_status: hash= 2057. fragments no.: 1, unused: 0
> bucket size: 4194304 - 8388608 (first 5982824)
>
>
> Is it a memory leak in one of these modules?
Peter found recently a lot of leaks in other presence modules (take a look to
the sr-dev list), so possible that they are more in this module.
Viele Grüße/ best regards,
Henning Westerholt
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
