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: [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
On Fri, Jul 16, 2010 at 4:51 PM, JR Richardson 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: [tree.c:139]: no more pkg mem
> 3(3018) ERROR: mi_fifo [fifo_fnc.c:509]: command (pdt_list) proc
JR Richardson wrote:
On Fri, Jul 16, 2010 at 4:51 PM, JR Richardson 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: [tree.c:139]: no more pkg mem
3(3018) ERROR: mi_fifo [fifo_fnc.c:509]: command
On Mon, Jul 19, 2010 at 2:41 AM, marius zbihlei wrote:
> JR Richardson wrote:
>>
>> On Fri, Jul 16, 2010 at 4:51 PM, JR Richardson
>> 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
> So I started seeing this issue with only 35K records in pdt database,
> I increased
> #define PKG_MEM_POOL_SIZE 8*1024*1024
> Then I was able to load 35K records with good results. I increased
> record count to 60K records and hit the limit again, pdt_list would
> not work with same "no more pkg
On Monday 19 July 2010, JR Richardson wrote:
> [..]
> When I added 180K records in the database, I got the "no more pkg mem"
> error again.
> I increased again:
> #define PKG_MEM_POOL_SIZE 32*1024*1024
> This allowed me to execute pdt_list with 180K records loaded.
>
> I increased database record
On Tuesday 20 July 2010, JR Richardson wrote:
> [..]
> So now I'm running out of shmem as well. After I loaded more than 320K
> records in the pdt database table, I started getting these errors:
> 0(17599) ERROR: pdt [pdtree.c:283]: bad parameters
> 0(17599) INFO: pdt [pdt.c:490]: no prefix found
Hi,
On 07/20/2010 11:21 AM, Henning Westerholt wrote:
On Monday 19 July 2010, JR Richardson wrote:
[..]
When I added 180K records in the database, I got the "no more pkg mem"
error again.
I increased again:
#define PKG_MEM_POOL_SIZE 32*1024*1024
This allowed me to execute pdt_list with 180K
Hi,
On 07/20/2010 11:27 AM, Henning Westerholt wrote:
On Tuesday 20 July 2010, JR Richardson wrote:
[..]
So now I'm running out of shmem as well. After I loaded more than 320K
records in the pdt database table, I started getting these errors:
0(17599) ERROR: pdt [pdtree.c:283]: bad parame
On Tuesday 20 July 2010, Elena-Ramona Modroiu wrote:
> > [..]
> > #define PDT_MAX_DEPTH32
>
> this defines the max length for prefixes (DIDs) that can be stored in
> the internal trees.
Hi Elena-Ramona,
ah, now i understand better - so my comment was misleading. Thanks for
clarification
2010/7/20 Elena-Ramona Modroiu :
> this is the option added to overcome the MI design limitations - while most
> of dumped structures are in shared memory, MI builds the output in PKG
> memory, resulting in insufficient space since shm is much bigger than pkg -
> also this sometime ended as well in
Hi,
On 07/16/2010 11:51 PM, JR Richardson 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: [tree.c:139]: no more pkg mem
3(3018) ERROR: mi_fifo [fifo_fnc.c:509]: command (pdt_list) processing failed
On Tuesday 20 July 2010, Iñaki Baz Castillo wrote:
> > this is the option added to overcome the MI design limitations - while
> > most of dumped structures are in shared memory, MI builds the output in
> > PKG memory, resulting in insufficient space since shm is much bigger than
> > pkg - also this
Hi,
On 07/20/2010 12:37 PM, Henning Westerholt wrote:
On Tuesday 20 July 2010, Iñaki Baz Castillo wrote:
this is the option added to overcome the MI design limitations - while
most of dumped structures are in shared memory, MI builds the output in
PKG memory, resulting in insufficient space
2010/7/20 Henning Westerholt :
>> Hi Elena. This is also I'm a bit afraid of when using MI command to
>> manage large ammount of records (LCR, locations, 'address'
>> entries...).
>> Wouldn't make sense MI to use shared memory instead of private memory?
>
> Hi Iñaki,
>
> this would be possible, but
>>> [..]
>>> When I added 180K records in the database, I got the "no more pkg mem"
>>> error again.
>>> I increased again:
>>> #define PKG_MEM_POOL_SIZE 32*1024*1024
>>> This allowed me to execute pdt_list with 180K records loaded.
>>>
>>> I increased database record count to 240K and got the "no
On Tuesday 20 July 2010, Iñaki Baz Castillo wrote:
> > another would be to partition the command execution in small steps
> > like we do for data loading in several modules.
>
> Yes, but this involves MI process to be designed for that, and it's
> not the case, right? This is, in case the retrieve
On 07/20/2010 05:06 PM, JR Richardson wrote:
[..]
When I added 180K records in the database, I got the "no more pkg mem"
error again.
I increased again:
#define PKG_MEM_POOL_SIZE 32*1024*1024
This allowed me to execute pdt_list with 180K records loaded.
I increased database record count to 240K
On Tue, Jul 20, 2010 at 12:04 PM, Elena-Ramona Modroiu
wrote:
> On 07/20/2010 05:06 PM, JR Richardson wrote:
>
> [..]
> When I added 180K records in the database, I got the "no more pkg mem"
> error again.
> I increased again:
> #define PKG_MEM_POOL_SIZE 32*1024*1024
>
On 07/20/2010 07:45 PM, JR Richardson wrote:
On Tue, Jul 20, 2010 at 12:04 PM, Elena-Ramona Modroiu
wrote:
On 07/20/2010 05:06 PM, JR Richardson wrote:
[..]
When I added 180K records in the database, I got the "no more pkg mem"
error again.
I increased again:
#define PKG_MEM_POOL_SI
On Tuesday 20 July 2010, JR Richardson wrote:
> [..]
> Here is an interesting observation:
> When I have 300K+ records in the pdt table, it seems like it will not
> load properly and the shmem is very low, as expected without a large
> memory pool needed to hold the records. Statistics show:
> shm
>> sip-router2:~# kamailio -V
>> version: kamailio 3.0.2 (i386/linux) a6141a
>> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
>> F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
>> USE_DNS_FAILOVER, USE
>> try to play with mysql module timeout parameter in case the records are not
>> loaded fast enough:
>>
>> http://kamailio.org/docs/modules/stable/modules/db_mysql.html#id2928400
>>
>> Regards,
>> Ramona
>
> Ok, I figured out that sr was taking about 9-10 seconds to load 300K
> records so I increa
23 matches
Mail list logo