(RADIATOR) RE: no timeout on database query

[Dave Kitabjian]

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> 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
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> ] 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: 

	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.

	 

	 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20080124/c7cd4f9e/attachment.html>