User Tools

Site Tools


tutorials:troubleshooting:memory

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
Next revision Both sides next revision
tutorials:troubleshooting:memory [2015/01/09 12:21]
miconda created
tutorials:troubleshooting:memory [2015/09/04 00:01]
miconda [Memory Manager Debugging]
Line 63: Line 63:
   * if the number of subscribers, traffic is constant, no larger data was reloaded (e.g., dispacher, lcr), then there is very likely a memory leak that has to be discovered and fixed   * if the number of subscribers, traffic is constant, no larger data was reloaded (e.g., dispacher, lcr), then there is very likely a memory leak that has to be discovered and fixed
  
-===== Troubleshooting ===== 
  
 ===== Memory Manager Debugging ===== ===== Memory Manager Debugging =====
Line 114: Line 113:
     * for SHM memory:     * for SHM memory:
 <code> <code>
-kamcmd cfg.set_now_int core mem_dump_shm+kamcmd cfg.set_now_int core mem_dump_shm 1
 </code> </code>
  
Line 148: Line 147:
 if($i>2000) if($i>2000)
 if($a->u.is_free==0) if($a->u.is_free==0)
 +printf "=========== non-free fragment: %d\n", $i
 +p $a
 +p (void*)((char*)($a)+sizeof(struct qm_frag))
 +printf "----------- content\n"
 p *$a p *$a
 end end
 +end
 +set $a = ((struct qm_frag*)((char*)($a)+sizeof(struct qm_frag)+((struct qm_frag*)$a)->size+sizeof(struct qm_frag_end)))
 +set $i = $i + 1
 +end
 +</code>
 +
 +An alternative is to print all used chunks, but be aware that it may take some time:
 +
 +
 +<code c>
 +set $i=0
 +set $a = mem_block->first_frag
 +while($a < mem_block->last_frag_end)
 +if($a->u.is_free==0)
 +printf "=========== non-free fragment: %d\n", $i
 +p $a
 +p (void*)((char*)($a)+sizeof(struct qm_frag))
 +printf "----------- content\n"
 +p *$a
 end end
 set $a = ((struct qm_frag*)((char*)($a)+sizeof(struct qm_frag)+((struct qm_frag*)$a)->size+sizeof(struct qm_frag_end))) set $a = ((struct qm_frag*)((char*)($a)+sizeof(struct qm_frag)+((struct qm_frag*)$a)->size+sizeof(struct qm_frag_end)))
Line 167: Line 189:
 gdb --batch --command=/tmp/kamailio-dump-used-pkg.gdb /usr/sbin/kamailio 21907 gdb --batch --command=/tmp/kamailio-dump-used-pkg.gdb /usr/sbin/kamailio 21907
 </code> </code>
 +
 +===== PKG With System Malloc =====
 +
 +Kamailio can be compiled to use system malloc and free for PKG needs. You have to remove the PKG_MALLOC define from Makefile.defs and can add DBG_SYS_MALLOC to get more verbosity with memory operations in debug mode.
 +
 +Next is a diff showing the changes in Makefile.defs, but note that lines may vary on your specific Kamailio version.
 +
 +<code c>
 +diff --git a/Makefile.defs b/Makefile.defs
 +index 3890668..12ca37a 100644
 +--- a/Makefile.defs
 ++++ b/Makefile.defs
 +@@ -621,7 +621,7 @@ C_DEFS= $(extra_defs) \
 +         -DSER_VER=$(SER_VER) \
 +         -DCFG_DIR='"$(cfg_target)"'\
 +         -DRUN_DIR='"$(run_target)"'\
 +-        -DPKG_MALLOC \
 ++        -DDBG_SYS_MALLOC \
 +         -DSHM_MEM  -DSHM_MMAP \
 +         -DDNS_IP_HACK \
 +         -DUSE_MCAST \
 +</code>
 +
 +After updating Makefile.defs recompile and reinstall.
 +
 +Other tools available out there (e.g., valgrind) can be then used to track the PKG memory operations done by Kamailio.
 +
 +===== OS Memory Reports =====
 +
 +It may happen that various tools report memory usage increase on the server. That could be due to a leak issue or due to caching done by kernel. The memory for cache can be reclaimed and it is better to verify whether the increase is due to it or not, before going ahead to investigate other applications.
 +
 +Kamailio itself uses in very few components extra memory directly from the system (those are the only ones that can cause a system memory leak). Most of the operations are done in the memory zone reserved at startup and when that is filled, it starts printing out of memory errors. Kamailio will not get at runtime more system memory for those operations, even there is sufficient available in the system - the size reserved at startup is fixed.
 +
 +Here is the article that presents better the situation:
 +
 +   * http://blog.logicmonitor.com/2014/10/09/more-linux-memory-free-memory-that-is-not-free-nor-cache/
 +
 +An relevant excerpt from the blog article:
 +
 +<code>
 +Looking at the contents of /proc/meminfo showed these two lines:
 +
 +Slab: 4126212 kB 
 +SReclaimable: 4096172 kB
 +
 +So – almost 4G of memory was in use by the kernel slab memory structures – but
 + almost all of that memory was reclaimable. (Or, in effect, free.)
 +
 +So reclaimable slab space is yet another way that Linux memory can be in
 + effect free, but not show up in the free memory statistics.
 +
 +</code>
 +
 +The respective memory can be reclaimed with command:
 +
 +<code>
 +sync; echo 3 > /proc/sys/vm/drop_caches
 +</code>
 +
tutorials/troubleshooting/memory.txt · Last modified: 2021/06/01 20:44 by giavac