(RADIATOR) RE: no timeout on database query
dave at netcarrier.com
Thu Jan 24 07:06:15 CST 2008
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.
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> 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 :-(
A few things to consider implementing if you are handling
lots-o-requests that have helped us out over the years running Radiator
1) Split Authentication and Accounting into 2 different Unix
2) Use InnoDB for Accounting records, row-level-locking has made a
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.
From: 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
Subject: Re: (RADIATOR) no timeout on database query
On 1/21/08, Ruud Besseling < ruudb at kpn.net
<mailto:ruudb at kpn.net> > wrote:
We use a mysql database to save all accounting data. Normally
database is not available the insert query
times out, the data is saved in a local file and radiator is
the next request.
However, when the network interface of the database server is
unexpectedly, the timeout does not occur
and radiator hangs.
Has anyone experienced the same problems and -more important-
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
radius processes running.
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the radiator