[Spce-user] kamailio-proxy.log error - mysql lost connection

[Matthew Ogden]

Thanks Andreas,

That's well put I guess. I  always respect your input.

But after your feedback, I realised, having a max calls is exactly this...
you are rating your system for max calls, and not letting it over that.
And that is far less complicated than looking at disk load.

So if you are going to use Cloud, ensure you have guaranteed IO. By the
way, I saw a recent email saying Amazon is now selling such services for
their Windows/Linux Virtual Machines.

> -----Original Message-----
> From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-
> bounces at lists.sipwise.com] On Behalf Of Andreas Granig
> Sent: 28 May 2013 04:08 PM
> To: spce-user at lists.sipwise.com
> Subject: Re: [Spce-user] kamailio-proxy.log error - mysql lost
connection
>
> Hi,
>
> On 05/28/2013 03:42 PM, Matthew Ogden wrote:
> > I realise with high IO load, things will timeout, but I would assume
> > that the components of SPCE have a method for dealing with this:
> >
> > 1)Stop new registrations (without banning unless the frequency is too
> > high -  a legitimate ban that may have been the cause of highio)
> >
> > 2)Honour existing registrations
> >
> > 3)Prioritise call tear downs
> >
> > 4)Because the thread happens synchronously for call tearups, and these
> > will be timing out, reply with a 503 or similar code before the final
> > timeout if unable to log data fast enough. Then log the timeout in
> > waitable / (and discardable if necessary) thread?
> >
> > "Crashing" is not really an option for a SIP server, current calls
> > should be more important than new calls etc. Current registrations and
> > re-registrations more important than new ones and so forth.
>
> None of the above options are really viable. A SIP message has to be
> received and parsed, and you'd want kamailio to somehow queue and re-
> order them based on the type. This is not something kamailio can do, and
> I'm not aware of any plans for them implementing such a thing.
>
> On the other hand, there is nothing which makes a SIP server more
special
> than a web server, the technical concept is really the same. If you have
> critical web sites (like, let's say, online banking), you need to scale
your
> infrastructure accordingly to handle the load you're expecting. You
can't
> just say that wiring new payments must have higher priority than say
> checking your account balance.
>
> If you run a critical network infrastructure, it's your responsibility
to
> estimate the expected traffic/load (e.g. via benchmarks and erlang
> calculations) and check whether the server you've put there can handle
this.
> If not, you need to either put a stronger server there, or scale the
load over
> more servers.
>
> Andreas
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user