(RADIATOR) Input queue size

[Guðbjörn S. Hreinsson]

Cheers,

this may be unrelated, but I am interested to any and all tuning 
listmembers have done in the OS for Radiator performance. We 
are running two radiator servers with one proxy radiator in front 
and a seperate sql machine and ldap machine.

Since we perform ldap auth the incoming requests are sequential 
which limits our rate of authentication. We have seen that we can 
handle at most about 1500 requests per minute per server during 
peak loads (server restarts etc.) This is mostly load from xDSL 
users (we do periodic tarpitting for "bad" users). 

We have also seen that at these peaks udp packets begin to be 
dropped (by the os I imagine) and aaa rates start to get worse. 
This drop in rates seems to related to the fact that if the radius 
servers do not respond in a timely fashion the NAS's begin to 
resend the radius requests adding to the incoming rate of packets, 
increasing the udp drop etc.

We actually monitor udp packet drops and restart the radiators 
which increases the rate for a while, until there is another udp queue 
buildup and udp packets start to be dropped, nas's start to resend 
packets etc.until the monitor script restarts the servers. 

Lengthening the udp queues seems to really have adverse effects on 
this situation. We have not really tried shortening the queue which 
might really have even more adverse effects, without testing though 
I can't tell. 

To counter this we have configured multiple instances of radiators 
for authentication&authorization and accounting and instances for 
seperate NAS's or NAS groups. This in effect simulates having a 
threaded radiator to reduce the effect of this sequential processing.

This has not seemed to be related to CPU load or network performance, 
we have looked at these in detail. We also looked at dropping radius 
packets which were x seconds old but there is no practical way to do 
this, since we really have no way of knowing when the NAS sent the 
udp packet (I wish radius supported tcp, it's much better situated for 
high traffic rates). 

We did an estimate once for how many packets would fit in the queue 
based on some average size but this did in the end have really no purpose. 

If anyone has input on this issue or OS tuning for Radiator I'd love 
to hear about it. Hope you understand my attempt to explain the above 
scenario. Basically we have a pretty stable environment today, but 
perhaps overly complex to manage because of the multiple instances. 

Hugh, is a "threaded" ldap handler on the horizon? Is this perl or 
radiator related?

Rgds,
-GSH

----- Original Message ----- 
From: "Hugh Irvine" <hugh at open.com.au>
To: "Claudio Lapidus" <c_lapidus at hotmail.com>
Cc: <radiator at open.com.au>
Sent: Wednesday, November 12, 2003 3:02 AM
Subject: Re: (RADIATOR) Input queue size


> 
> Hello Claudio -
> 
> This is really an operating system issue, as the UDP buffer space is 
> managed by the OS.
> 
> You should have a look at "netstat" and friends.
> 
> Solaris may also have addtional tools that allow you to look at what 
> the system is doing.
> 
> regards
> 
> Hugh
> 
> 
> On 12/11/2003, at 1:28 PM, Claudio Lapidus wrote:
> 
> > Hello Hugh,
> >
> > Is there a way to inspect the length of the input queue during 
> > runtime? I'm
> > running Radiator 3.6 on Solaris 8, Perl 5.8.0, no monitor setup.
> >
> > thanks in advance
> > cl.
> > ===
> > 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.
> >
> >
> 
> NB: have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> 
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
> 
> ===
> 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.
> 
===
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.