Documentation |
Documentation.TroubleShooting-OutOfMem HistoryHide minor edits - Show changes to markup March 16, 2021, at 10:12 AM
by
- Changed line 33 from:
to:
July 27, 2020, at 09:56 AM
by
- Changed line 29 from:
1. to:
1. Enable memory debugging June 03, 2019, at 10:19 PM
by
- Changed line 33 from:
to:
June 03, 2019, at 10:19 PM
by
- Changed line 33 from:
to:
June 03, 2019, at 10:19 PM
by
- Changed line 33 from:
to:
June 03, 2019, at 10:18 PM
by
- Changed lines 19-22 from:
TEST: wait ~ 20 minutes without any kind of load the proxy. 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. to:
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. Changed lines 27-28 from:
If it is about a memory leak or a memory corruption issue, you need to compile the debug support into memory manager. To do so, follow the next steps: to:
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: Changed lines 30-35 from:
2. recompile everything to:
2. OpenSIPS 2.4 and below: recompile everything Changed lines 57-61 from:
2. At run time - you may check the memory status by sending SIGUSR1 signal to the process (do "kill -SIGUSR1 OPENSIPS_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... to:
2. At run time
October 11, 2017, at 11:30 AM
by
- Changed line 13 from:
b) memory leak - some memory id not properly freed, making all the memory unavailable (not used, but still allocated) to:
b) memory leak - some memory ids are not properly freed, so they will gradually fill up all available memory (not used, but still allocated) June 13, 2016, at 06:21 PM
by
- Changed line 42 from:
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: to:
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: Changed line 56 from:
2. **At run time** - you may check the memory status by sending SIGUSR1 signal to the process (do "kill -SIGUSR1 OPENSIPS_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... to:
2. At run time - you may check the memory status by sending SIGUSR1 signal to the process (do "kill -SIGUSR1 OPENSIPS_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... June 13, 2016, at 06:21 PM
by
- Changed line 36 from:
3. set memlog=1 in your configuration script (to get the memory messages) - it must be lower than debug. to:
3. set memdump = 1 in your configuration script (to get the memory messages) - it must be lower than debug. March 29, 2016, at 02:30 PM
by
- Changed lines 30-32 from:
to:
March 29, 2016, at 02:30 PM
by
- Changed line 32 from:
to:
March 29, 2016, at 02:30 PM
by
- Changed lines 30-31 from:
to:
September 09, 2014, at 03:47 PM
by
- Changed line 31 from:
to:
September 09, 2014, at 03:47 PM
by
- Changed line 31 from:
to:
September 09, 2014, at 03:46 PM
by
- Changed line 25 from:
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). to:
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). September 09, 2014, at 03:45 PM
by
- Changed line 25 from:
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 (in MB). to:
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). September 09, 2014, at 03:45 PM
by
- Changed line 25 from:
If the memory pool is too small, just go in config.h and increase the size of the memory pool - for SHM or PKG. to:
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 (in MB). October 30, 2013, at 10:19 AM
by
- Changed line 1 from:
Documentation -> TroubleShooting -> Out Of Memoryto:
Documentation -> TroubleShooting -> Out Of MemoryMay 09, 2013, at 02:53 PM
by
- Changed line 1 from:
to:
Documentation -> TroubleShooting -> Out Of MemoryMay 09, 2013, at 02:48 PM
by
- Changed lines 1-2 from:
Resources -> Documentation -> Out Of Memoryto:
April 24, 2013, at 07:33 PM
by
- Added lines 1-57:
Resources -> Documentation -> Out Of MemoryWhat to do if "out of memory" or "no more memory" messages are generated by OpenSIPS? Potential causesThere 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 causeIf 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 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 itIf 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 or a memory corruption issue, you need to compile the debug support into memory manager. To do so, follow the next steps: 1.
2. recompile everything 3. set memlog=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 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 OPENSIPS_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.opensips.org mailing list. |