-----Original Message----- From: Kostas Kalevras [mailto:[EMAIL PROTECTED] Sent: Tue 10/5/2004 11:50 PM To: [EMAIL PROTECTED] Cc: Subject: Re: 0.9.3 Solaris performance problem On Tue, 5 Oct 2004, Stungo, Jamie wrote:
> Hi all,
>
> We are experiencing some unexpected behaviour of freeradius on our Solaris 9
> platform. We use two V240 dual processor SPARC machines, LDAP back-end, flat
> file accounting. I have heavily indexed the directory and it seems lightning
> fast, slapd is running at 0.2% most of the time, yet radiusd chews 95+% of
> CPU0 and I have to re-nice the process to get a workable shell! This is on
> both machines. As I understand it we can't spread the load across both CPUs?
>Freeradius is multithreaded, so the load sould be spread across both CPUs. >What
>type is the CPU usage, kernel/user/io?
CPU states: 0.0% idle, 14.6% user, 85.4% kernel, 0.0% iowait, 0.0% swap
>
> I don't believe that the problem is caused by the number of lookups as it was
> running at fairly low loads (with 10k subs) until we recently added another
> couple of thousand (who match in the users file instead of dropping through to
> the LDAP).
>I really don't understand this paragraph. What do you mean by subs? Couple
>thousand of what? Match in the users file?
Subs = subscribers/users. Approximately half the users would do two matches in the
users file, the rest just one.
> Our users file has about 130 DEFAULT matches (total) as follows:
>That's plenty of DEFAULT entries. Remember that for each request the server
>might try matching 130 entries. Make sure you have the best
>matching entries first. Though i would not bet my money on that being the >root cause.
It's a good point, I have moved around some entries and I believe this has slightly
improved things, however you're right and this is not the main problem.
>
> DEFAULT Suffix == "@subdomain.provider.com", NAS-IP-Address == 10.0.0.1,
> Auth-Type := Accept
> Service-Type = Framed,
> Framed-Protocol = PPP,
> ERX-Virtual-Router-Name = PROVIDER1,
> Tunnel-Type = L2TP,
> Tunnel-Medium-Type = IP,
> ERX-Tunnel-Password = xxxxxx,
> Tunnel-Client-Endpoint = 172.X.X.X,
> Tunnel-Server-Endpoint = 172.X.X.Y,
> Tunnel-Assignment-Id = xxxx,
> Tunnel-Client-Auth-Id = blahblah,
> Tunnel-Server-Auth-Id = blehbleh
>
> DEFAULT Suffix == "@subdomain.provider.com", NAS-IP-Address == 10.0.0.2,
> Autz-Type := WholesaleLDAP, Auth-Type := Accept
> Service-Type = Framed,
> Framed-Protocol = PPP,
> ERX-Virtual-Router-Name = PROVIDER1,
> Tunnel-Type = L2TP,
> Tunnel-Medium-Type = IP,
> ERX-Tunnel-Password = xxxxxx,
> Tunnel-Client-Endpoint = 172.X.X.X,
> Tunnel-Server-Endpoint = 172.X.X.Y,
> Tunnel-Assignment-Id = xxxxx,
> Tunnel-Client-Auth-Id = blahblah,
> Tunnel-Server-Auth-Id = blehbleh
>
> We get a lot of "Unresponsive child" and "Dropping conflicting packet" errors
> in our radius log, as well as the max number of threads hitting its ceiling
> (128). Suggestions for a reasonable figure for this for our hardware platform
> would be helpful to know. It seems to hit its roof at around 250. I'm not sure
> whether better performance would be gained from allowing it to peak or to keep
> it low.
>Could you post your authorize,authenticate,session and accounting sections? >Do you
>check for double logins?
We do check for double login checks by means of an LDAP lookup (WholesaleLDAP) on
about half the users.
authorize {
#
# The preprocess module takes care of sanitizing some bizarre
# attributes in the request, and turning them into attributes
# which are more standard.
#
# It takes care of processing the 'raddb/hints' and the
# 'raddb/huntgroups' files.
#
# It also adds a Client-IP-Address attribute to the request.
preprocess
#
# If you want to have a log of authentication requests,
# un-comment the following line, and the 'detail auth_log'
# section, above.
auth_log
#
# The chap module will set 'Auth-Type := CHAP' if we are
# handling a CHAP request and Auth-Type has not already been set
chap
mschap
# attr_filter
#
# This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
# authentication.
#eap
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line.
# digest
#
# Look for IPASS style 'realm/', and if not found, look for
# '@realm', and decide whether or not to proxy, based on
# that.
# realmslash
suffix
#
# If you are using /etc/smbpasswd, and are also doing
# mschap authentication, the un-comment this line, and
# configure the 'etc_smbpasswd' module, above.
# etc_smbpasswd
#
# If the users are logging in with an MS-CHAP-Challenge
# attribute for authentication, the mschap module will find
# the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
# to the request, which will cause the server to then use
# the mschap module for authentication.
# moved mschap up
# mschap
# The ldap module will only be used if the Autz-Type:=LDAP is set in the users
# files. This will in turn set the Auth-Type:=LDAP if it has not already
# been set
autztype DirectLDAP {
direct
}
autztype WholesaleLDAP {
wholesale
}
#
# Read the 'users' file
files
# daily
}
authenticate {
#
# PAP authentication, when a back-end database listed
# in the 'authorize' section supplies a password. The
# password can be clear-text, or encrypted.
Auth-Type PAP {
pap
}
#
# Most people want CHAP authentication
# A back-end database listed in the 'authorize' section
# MUST supply a CLEAR TEXT password. Encrypted passwords
# won't work.
Auth-Type CHAP {
chap
}
#
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line.
# digest
#
# Pluggable Authentication Modules.
# pam
#
# See 'man getpwent' for information on how the 'unix'
# module checks the users password. Note that packets
# containing CHAP-Password attributes CANNOT be authenticated
# against /etc/passwd! See the FAQ for details.
#
# unix
# Uncomment it if you want to use ldap for authentication
Auth-Type LDAP {
direct
}
#
# Allow EAP authentication.
# eap
}
session {
# radutmp
# sql
}
accounting {
acct_unique
detail
# daily
unix # wtmp file
radutmp
# sql
# sradutmp
# main_pool
}
>
>
> The lookups we're doing don't seem particularly CPU intensive... in the one
? case we're matching domain suffix and NAS-IP-Address and building a tunnel, in
? the other the same but doing a quick lookup in addition. From what I've read
> What quick lookup? Lookup on where? ldap?
Yes, this is the WholesaleLDAP lookup I'm referring to.
> so far, matches like this should be extremely quick to perform, even with a
> big users file. I'd like to turn to my LDAP as the source of the problem but I
> really don't believe it's at fault.
>
> Any and all help gratefully received.
>
> Cheers,
>
> Jamie Stungo
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
<<winmail.dat>>
