[Serusers] No mem for sip_msg

[Rork, Joseph (J.P.)]

Thanks, that worked.  No memory leaks yet, but I have a bit bucket just in case.

-----Original Message-----
From: Andrei Pelinescu-Onciul [mailto:pelinescu-onciul at fokus.fraunhofer.de] 
Sent: Friday, September 19, 2003 2:35 PM
To: Rork, Joseph (J.P.)
Cc: 'Serusers (serusers at lists.iptel.org)'
Subject: Re: [Serusers] No mem for sip_msg


On Sep 19, 2003 at 14:31, Rork, Joseph (J.P.) <jrork at ford.com> wrote:
> What do you suggest it be increased too?  Currently the line reads 
> '#define PKG_MEM_POOL_SIZE 1024*1024'
Try 4096*1024, or  10240*1024 (10Mb). As long as you have enough RAM you can increase it :-)

Andrei
> 
> -----Original Message-----
> From: Andrei Pelinescu-Onciul 
> [mailto:pelinescu-onciul at fokus.fraunhofer.de]
> Sent: Friday, September 19, 2003 2:18 PM
> To: Rork, Joseph (J.P.)
> Cc: 'Serusers (serusers at lists.iptel.org)'
> Subject: Re: [Serusers] No mem for sip_msg
> 
> 
> On Sep 19, 2003 at 14:06, Rork, Joseph (J.P.) <jrork at ford.com> wrote:
> > I've recently gone back to MySql v4.0, w/ SER 8.11.  I'm trying to 
> > log
> > in and I am seeing the following message in the syslog.
> > 
> > Sep 19 17:50:17 sip2 ser[2066]: ERROR: receive_msg: no mem for 
> > sip_msg
> > 
> > I have plenty of memory in my system.  Has anyone else run into this
> > problem, and if so, how did you fix it?
> 
> The short fix is edit config.h and change PKG_MEM_POOL_SIZE. Right now 
> is 1Mb, increase it.
> 
> Explanation:
>  ser uses 2 types of memory, shared and "local". The "local" memory is  
> not shared between the processes and it's faster to allocate since we  
> don't need to lock on malloc.  The shared mem. size can be increased 
> form the command line (-m  size_in_mb). The default is 32Mb.  The 
> "local" mem. maximum size is fixed to 1Mb (PKG_MEM_POOL_SIZE). We  
> haven't needed more so far. In your case probably ser uses a lot of  
> "local" mem. when it tries to load some of the databases in RAM on  
> init. This is a known problem, and in the future we'll solve it 
> without  increasing PKG_MEM_POOL_SIZE, but for now this is the only 
> solution.  (I assume this is the problem in your case, but you could 
> have also  found a mem. leak, we would need the full logs and maybe a 
> debug build  to say for sure).
> 
> Andrei