(RADIATOR) RE: no timeout on database query

[Ruud Besseling]

Thank you all for the answers, now we know that the problem is not 
unique to us. Unfortunatly no distinct solution is available yet.

We'll have to investigate further... and keep you posted.

kind regards
Ruud Besseling



Dave Kitabjian wrote:
>
> Thanks for the suggestions. But performance isn’t our problem; we’re 
> operating way under capacity (we’ve implemented almost all your 
> suggestions anyway). Our problem was specifically the “lockup after DB 
> interface outage” issue.
>
> Dave
>
> ------------------------------------------------------------------------
>
> *From:* Nick Rogness [mailto:nick at rogness.net]
> *Sent:* Wednesday, January 23, 2008 9:02 PM
> *To:* Dave Kitabjian
> *Cc:* Ruud Besseling; radiator at open.com.au; Greg Evanyke
> *Subject:* Re: no timeout on database query
>
> On 1/23/08, *Dave Kitabjian* <dave at netcarrier.com 
> <mailto:dave at netcarrier.com>> wrote:
>
>     Thanks for sharing, as this has haunted us for some time as well.
>     It's helpful to hear your analysis of the cause. We were forced to
>     relax concurrency enforcement (Simultaneous Use, via MySQL)
>     because a situation like this knocked both our primary and
>     secondary servers completely offline L
>
> A few things to consider implementing if you are handling 
> lots-o-requests that have helped us out over the years running 
> Radiator and MySQL:
>
> 1) Split Authentication and Accounting into 2 different Unix processes.
>
> 2) Use InnoDB for Accounting records, row-level-locking has made a 
> huge difference
>
> 3) Use local replication slaves whenever you need to read something 
> out of MySQL
>
> 4) Use LDAP instead of MySQL for Authentication if at all possible
>
> Making these changes have increased performance 10 fold or so. You 
> should be able to do 20-30 radius requests per second without much 
> effort. If you can't, then something is slow.
>
> Dave
>
>     ------------------------------------------------------------------------
>
>     *From:* owner-radiator at open.com.au
>     <mailto:owner-radiator at open.com.au> [mailto:
>     owner-radiator at open.com.au <mailto:owner-radiator at open.com.au>]
>     *On Behalf Of *Nick Rogness
>     *Sent:* Tuesday, January 22, 2008 12:18 PM
>     *To:* Ruud Besseling
>     *Cc:* radiator at open.com.au <mailto:radiator at open.com.au>
>     *Subject:* Re: (RADIATOR) no timeout on database query
>
>     On 1/21/08, *Ruud Besseling* < ruudb at kpn.net
>     <mailto:ruudb at kpn.net>> wrote:
>
>     Hello,
>
>     We use a mysql database to save all accounting data. Normally when the
>     database is not available the insert query
>     times out, the data is saved in a local file and radiator is ready for
>     the next request.
>
>     However, when the network interface of the database server is
>     going down
>     unexpectedly, the timeout does not occur
>     and radiator hangs.
>
>     Has anyone experienced the same problems and -more important- does
>     anyone have a solution?
>
>
>     We are using Radiator 3.13, MySQL 5.0.41, DBI 1.6 and DBD 4.005
>     We use several servers and on each server there are several
>     accounting
>     radius processes running.
>
>     [snip]
>
>     I have experienced this same problem for years with Radiator
>     including and upto 3.13 with Mysql5.0 and MySQL5.1. If the
>     database server goes away or takes time to complete in the middle
>     of a SQL execution statement, the server hangs (blocks) and the
>     socket queue fills up. My advise to you is, don't let it happen. A
>     significant amount of tuning needs to be done if you are dealing
>     with a lot of Radius requests.
>
>     I do not know how much Hugh and crew can do to help you out as I
>     think it is probably a limitation of Perl DBI/DBD.
>
>     Haven't tried this in v4.0 yet.
>
>
> ______________________________________________________________________________________
> This inbound message to KPN has been checked for all known viruses by 
> KPN MailScan,
> powered by MessageLabs.
> For further information visit: http://www.kpn.com, keyword 'Mailscan'
> ______________________________________________________________________________________

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.