– Kamailio SIP Server –

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
troubleshooting:memory [2011/02/04 20:20] – 85.178.105.99troubleshooting:memory [2011/10/06 12:03] (current) – [How to handle it] 83.136.33.3
Line 1: Line 1:
 +====== Troubleshooting "out of memory" or "no more memory" messages ======
  
 +
 +[color=red]What to do if "out of memory" or "no more memory" messages are generated by Kamailio (OpenSER)?[/color]
 +
 +===== Potential causes =====
 +
 +There are two cause that may lead to memory starvation:
 +
 +a) a small pool of memory - the configured memory is not enough and no more memory can be allocated.
 +
 +b) memory leak - some memory id not properly freed, making all the memory unavailable (not used, but still allocated)
 +
 +===== Determining the cause =====
 +
 +If the memory starvation is because of a too small pool of memory, by stopping the traffic on the proxy (without stopping the proxy), the allocated memory will be freed in time (as transactions and location records are freed).
 +TEST: wait ~ 20 minutes without any kind of load the proxy. Test the proxy by placing several calls; if the memory erros pop up again once the traffic is resumed, it means it's a memory leak somewhere; If not sure of the result, consider it's a memory leak.
 +
 +===== How to handle it =====
 +
 +If the memory pool is too small, just go in config.h and increase the size of the memory pool - for SHM or PKG.
 +
 +If it is about a memory leak, you need to compile the debug support into memory manager. To do so, follow the next steps: (Note: 3.1 release has memory debug enabled by default. Check if your binary has already support by "kamailio -V|grep DBG_QM_MALLOC".)
 +
 +1. edit Makefile.defs file and remove from the DEFS string the F_MALLOC define (delete "-DF_MALLOC" line) and add the DBG_QM_MALLOC define (insert a "-DDBG_QM_MALLOC" line).
 +
 +2. recompile everything
 +
 +3. set memlog=1 in your configuration script (to get the memory messages the "memlog" value must be smaller or equal to the "debug" value)
 +
 +4. restart your proxy 
 +
 +Now, you may check the memory status in two situations:
 +
 +1. **At shutdown** - just stop the proxy - the memory manager will dump the memory status. Normally most of the memory is cleaned during shutdown. If there is memory leak, it should be visible as not-freed memory. A memory status looks like:
 +     0(17665) Memory status (shm):
 +     0(17665) qm_status (0xb5a7e000):
 +     0(17665)  heap size= 33554432
 +     0(17665)  used= 1592952, used+overhead=1811564, free=31742868
 +     0(17665)  max used (+overhead)= 1811564
 +     0(17665) dumping all alloc'ed. fragments:
 +     0(17665)       0. N  address=0xb5ab240c frag=0xb5ab23f4 size=4 used=1
 +     0(17665)             alloc'd from mem/shm_mem.c: shm_mem_init_mallocs(199)
 +     0(17665)         start check=f0f0f0f0, end check= c0c0c0c0, abcdefed
 +     0(17665)       1. N  address=0xb5ab2440 frag=0xb5ab2428 size=4 used=1 
 +     0(17665)             alloc'd from timer.c: init_timer(52)
 +     0(17665)         start check=f0f0f0f0, end check= c0c0c0c0, abcdefed
 +
 +2. **At run time** - you may check the memory status by sending SIGUSR1 signal to the process (do "kill -SIGUSR1 OPENSER_PID") - it will dump the SHM and PKG (only for that process) memory status. It is highly recommended to do this after waiting about 20 minutes to be sure that as much as possile memory is freed - all temporary memory used during processing is freed by lack of load on the proxy. Go through the log and see if there is something suspicious, like too much memory still allocated from same place, etc...
 +
 +If you have no clue how to interpret the logs for memory status, post it on a FTP or HTTP server and send the link on the devel@lists.kamailio.org mailing list.
 +
 +With 3.x versions, you have to load ctl and cfg_rpc modules and execute:
 +
 +<code>
 +sercmd cfg.set_now_int core mem_dump_pkg <pid>
 +</code>
 +
 +Along with the processing of first SIP message coming to that PID, you get the status of pkg memory in syslog.
 +
 +===== Walking through PKG with gdb =====
 +
 +Print used chunks of the first 2000 to 10000 if compiled with PKG debug mode:
 +
 +<code>
 +set $i=0
 +set $a = mem_block->first_frag
 +while($i<10000)
 +if($i>2000)
 +if($a->u.is_free==0)
 +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 $i = $i + 1
 +end
 +
 +</code>
 +
 +===== Troubleshooting Stuff =====
 +
 +{{indexmenu>troubleshooting|js}}

Trace: • index-functions • private-memory-size • index-functions • index-functions • report-an-issue • main-index