[Serusers] SER Reports "out of memory"

[Java Rockx]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050530/e9c548ed/attachment.htm>