[Serusers] memory configuration

yserge yserge at newxt.com
Tue Nov 8 00:21:15 CET 2005


That's what I first tried.. I tried to start with 512M.. No difference
whatsoever. 

Then, checking the source code, it looks like it is the "PKG_MALLOC"
macro that fails, which , AFAIU, is not a shared memory.

Sergei 

> Hello,
> 
> try to start SER with more shared memory next time (with that amount of memory 
> you use only a fraction of the memory). I'm not 100% sure but I think SER 
> uses shared memory when loading the location table. Thus it runs probably 
> pretty soon out of shared memory with such a big subscriber population.
> 
>   Nils
> 
> On Monday 07 November 2005 22:23, yserge wrote:
> > Hello,
> >
> > I am having some problems configuring memory for SER..
> >
> > Here is what I have in my test instance:
> >
> > Server: Linux x64
> > Real Memory: 4GB
> > Database: MySQL/NDB
> > SER Shared memory: 256M
> > Children: 16
> > Subscribers: 40000
> >
> > In test environment:
> > Registrations per sec: 120
> > Call per second: 120
> >
> > When the SER process was started last week, it had only 4000 subscribers
> > provisioned. Then another 36000 subscribers were provisioned. The SER
> > was running fine. But when I decided to bounce SER, it would not
> > restart.
> >
> > It seems from the log file that SER ran out of memory trying to load the
> > LOCATION database into memory upon startup, failing around row #3500.
> > LOCATION table had in excess of 10000 records at that point.
> >
> > The related piece of the logfile is below..
> >
> >
> > I wonder whether it is a matter of configuration or is it a bug.. The
> > system definitely seem to have enough memory to store those few tens of
> > thousands of records.. Even at 1K each, it amounts to nothing..
> > Especially given that at runtime it handles that amount of location info
> > easily.. It's only a startup that seems to be a problem. I tried to play
> > with giving it more or less of shared memory.. It does not seem to be
> > relevant..
> >
> > For now I just have to clean up the LOCATION table each time before
> > restarting SER. Obviously, it is not a nice workaround..
> >
> >
> > Thanks,
> > Sergei
> >
> >
> >
> >
> > Mon Nov  7 12:29:59.281894 200: 0
> > (0):DEBUG:fixing /usr/local/ser/lib/ser/modules/registrar.so lookup
> > Mon Nov  7 12:29:59.281964 200: 0(0):DEBUG:get_connection(): Connection
> > not found in the pool
> > Mon Nov  7 12:29:59.282329 200: 0(0):DEBUG:preload_udomain(): Table is
> > empty
> > Mon Nov  7 12:29:59.282342 200: 0(0):DEBUG:release_connection():
> > Removing connection from the pool
> > Mon Nov  7 12:29:59.282360 200: 0
> > (0):DEBUG:fixing /usr/local/ser/lib/ser/modules/registrar.so save
> > Mon Nov  7 12:29:59.282414 200: 0(0):DEBUG:get_connection(): Connection
> > not found in the pool
> > Mon Nov  7 12:29:59.357157 200: 0(0):WARNING:convert_row(): No memory
> > left
> > Mon Nov  7 12:29:59.357189 200: 0(0):WARNING:convert_rows(): Error while
> > converting row #3445
> > Mon Nov  7 12:29:59.357413 200: 0(0):WARNING:convert_result(): Error
> > while converting rows
> > Mon Nov  7 12:29:59.357424 200: 0(0):WARNING:store_result(): Error while
> > converting result
> > Mon Nov  7 12:29:59.357432 200: 0(0):WARNING:preload_udomain(): Error
> > while doing db_query
> > Mon Nov  7 12:29:59.357438 200: 0(0):WARNING:register_udomain(): Error
> > while preloading domain 'location'
> > Mon Nov  7 12:29:59.357447 200: 0(0):DEBUG:release_connection():
> > Removing connection from the pool
> > Mon Nov  7 12:29:59.357856 200: 0(0):WARNING:domain_fixup(): Error while
> > registering domain
> > ERROR: error -1 while trying to fix configuration
> > Mon Nov  7 12:29:59.357901 200: 0(0)::DEBUG: tm_shutdown : start
> > Mon Nov  7 12:29:59.357913 200: 0(0)::DEBUG: unlink_timer_lists :
> > emptying DELETE list
> > Mon Nov  7 12:29:59.357920 200: 0(0)::DEBUG: tm_shutdown : emptying hash
> > table
> > Mon Nov  7 12:29:59.359085 200: 0(0)::DEBUG: tm_shutdown : releasing
> > timers
> > Mon Nov  7 12:29:59.359108 200: 0(0)::DEBUG: tm_shutdown : removing
> > semaphores
> > Mon Nov  7 12:29:59.359114 200: 0(0)::DEBUG: tm_shutdown : destroying
> > tmcb lists
> > Mon Nov  7 12:29:59.359122 200: 0(0)::DEBUG: tm_shutdown : done
> > Mon Nov  7 12:29:59.359143 200: 0(11662):DEBUG:shm_mem_destroy
> > Mon Nov  7 12:29:59.359154 200: 0(11662):DEBUG:destroying the shared
> > memory lock
> >
> >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers




More information about the sr-users mailing list