JR Richardson wrote:
On Fri, Jul 16, 2010 at 4:51 PM, JR Richardson jmr.richardson@gmail.com wrote:
Hi All,
I loaded up the PDT database with about 35K records and when I issue the commad "kamctl fifo pdt_list" I get:
3(3018) ERROR: <core> [tree.c:139]: no more pkg mem 3(3018) ERROR: mi_fifo [fifo_fnc.c:509]: command (pdt_list) processing failed
Searching around I found the http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:memory which suggest I adjust the pkg mem size in config.h.
In config.h, I found:
/*used only if PKG_MALLOC is defined*/ #define PKG_MEM_POOL_SIZE 4*1024*1024
So is this what I am supposed to adjust? Maybe try: #define PKG_MEM_POOL_SIZE 4*2048*2048 or #define PKG_MEM_POOL_SIZE 8*1024*1024
I tried #define PKG_MEM_POOL_SIZE 8*1024*1024 and recompiled with good results, was able to run pdt_list just fine. So what do I look for in the memory statistics to show how much memory to configure when using large database record sets? And if I need to go to 16* or 32*, would that have any adverse affect on any other kamailio operations?
Hello JR,
Compile kamailio with memory debug support. Modify Makefile.vars and set MEMDBG to 1 . In the config file(kamailio.cfg), set memlog to a lower level than the general debug level. You can do a dump of pkg (private) memory by sending a SIGUSR1 to one of the worker process ('kamctl ps' to find the pid). Unless you are working with a huge number of calls, I can't see why you need more than 8 MB or 10 maximum. Carefull if you have a 64 bit system you might need just a little more.
Which one would be a logical adjustment? Also, is there a correlation between pkg mem and database record size as related to pdt_list?
The idea is to have a few 100K records loaded in kamailio and be able to perform "kamctl fifo pdt_list | grep 512345" to show this prefix route. But without enough memory, doesn't work.
AFAIK, these mi commands will construct a complete result tree, thus meaning it should have enough memory for 100K records. If it works with 8 MB it is ok . Keep in mind that the memory dump is not that usefull to track these OOM condition, it is usefull to track memory leaks, as after the OOM condition happens the already malloc'ed memory is free'd. It would be usefull to test that is those OOM conditions, the free is done corectly and no leaks are induced
Cheers Marius
Thanks.
JR
JR Richardson Engineering for the Masses
Thanks.
JR