[Serusers] SER Reports "out of memory"

Greger V. Teigre greger at teigre.com
Mon May 30 22:04:49 CEST 2005


Yes, good point, but I don't like the solution. Both doing t_replicate AND DB replication is replication at both layers... I think we here have another argument for replication at the application layer. I'm starting to get blurred vision here: What was the reason for doing DB-level replication in the first place? (And BTW, what do you gain?)
g-)

---- Original Message ----
From: Java Rockx
To: Karl H. Putz
Cc: serusers
Sent: Monday, May 30, 2005 05:07 PM
Subject: Re: [Serusers] SER Reports "out of memory"

> Good point. So then perhaps t_replicate() [AND] save_memory() should
> be used as normal. And SER should then just start up using a
> lazy-loading mechanism. Eventually all SER routers in the farm would
> then have a fully populated cache and the problem would be solved.   
> 
> In other words the SER server that physically recieves the original
> REGISTER message would save() and t_replicate(). 
> 
> All the peers in the farm that receive a REGISTER via the
> t_replicate() function would only use save_memory(). 
> 
> MySQL replication still occurs and if a SER server is restarted it
> doesn't attempt to load usrloc info upon startup, but rather loads it
> over a period of time. All the while, if a usrloc record is looked-up
> and it is on in cache, then SER would query MySQL for the correct
> ucontact record.    
> 
> Thanks for the qustion --- I hadn't thought about that before.
> 
> Regards,
> Paul
> 
> 
> On 5/30/05, Karl H. Putz <kputz at columbus.rr.com> wrote:
>> -----Original Message-----On Behalf Of Jiri Kuthan
>> Sent: Monday, May 30, 2005 5:36 AM
>> At 03:40 AM 5/30/2005, Java Rockx wrote:
>>> Currently, usrloc is replicated via t_replicate() using
>>> db_mode=writeback. 
>>> 
>>> However, our lazy-load patch would obsolete the need for
>> t_replicate() because we have multiple MySQL servers that are
>> active-active so __all__ replication really occurs at the database
>> layer rather than the SIP layer.
>> 
>> So this is the point which I am still struggling with. I mean
>> generally there is a problem
>> of read-write intenstive UsrLoc operations. We can move it from
>> SIP to DB. However, whichever
>> layer we choose to solve the problem, it takes careful
>> dimensioning. Otherwise the
>> replication mechanism may cause peformance problems.
>> 
>> What Mysql setup are you exactly using? Cluster? Master/slave
>> replication? 
>> 
>> Otherwise I think that the cache policy "load-on-demand" makes sense.
> 
> If pure DB replication is used, what would happen in the following
> scenario: 
> 
> A given user receives multiple calls such that more than 1 physical
> SER 
> server has userloc
> cache populated.
> 
> The user then phsyically moves or changes return contact registration
> information and re-registers.
> 
> It seems that the specific SER server that handled the registration
> would 
> update cache and the
> backend DB would be updated.  But any attempt to contact the user
> through a 
> SER server that has
> not yet expired the old cache info would fail.
> 
> 
> Karl
> 
>> 
>> -jiri
>> 
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>> 
> 
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050530/135abe8b/attachment.htm>


More information about the sr-users mailing list