Documentation -> TroubleShooting -> Out Of Memory

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 ids are not properly freed, so they will gradually fill up all available memory (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 ~5 minutes without any kind of load the proxy, so the majority of calls get a chance to close. Test the proxy by placing several calls; if the memory errors 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, you can increase the available pools with the -m (shared mem) and -M (per process mem) parameters of the opensips binary (values are given in MB).

If it is about a memory leak or a memory corruption issue, you need to compile or enable the debug support into the memory manager. To do so, follow the next steps:

1. Enable memory debugging

• OpenSIPS 1.7 and below (recompile required): 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).
• OpenSIPS 1.8 - 2.1 (recompile required): Run 'make menuconfig' from the main sources folder, go to 'Configure Compile Options', then to 'Configure Compile Flags', use the arrow keys to go down and uncheck F_MALLOC via the spacebar key, and check DBG_QM_MALLOC. Then hit 'q' to go back to the previous menu, and hit 'Save Changes'.
• OpenSIPS 2.2 - 2.4 (recompile required): Run 'make menuconfig' from the main source dir -> Configure Compile Options -> Configure Compile Flags -> check QM_MALLOC and DBG_MALLOC. Then hit 'q' to go back to the previous menu, and hit 'Save Changes'.
• OpenSIPS 3.0 and above: edit /etc/default/opensips (on Debian) or /etc/sysconfig/opensips (on Red Hat), and specify the OPTIONS="-a Q_MALLOC_DBG" command-line option for the opensips binary. You only have to restart OpenSIPS now, not yet though! (see below)

2. OpenSIPS 2.4 and below: recompile everything

3. set memdump = 1 in your configuration script (to get the memory messages) - it must be lower than debug.

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 a 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

• OpenSIPS 2.4 and below - you may check the memory status by sending SIGUSR1 signal to the process (do "kill -SIGUSR1 OPENSIPS_PID") - it will dump the PKG (only for that process) memory status. To obtain the status of the SHM pool, pick the attendant process PID (run "opensipsctl fifo ps" and pick 1st PID). It is highly recommended to do this after waiting about 20 minutes to be sure that as much as possible 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...
• OpenSIPS 3.0 and above - the memory status can be checked using the opensips-cli -x mi mem_pkg_dump <pid> and opensips-cli -x mi mem_shm_dump MI commands. Same general recommendations as above.

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.opensips.org mailing list.