Have you tried putting the process under truss (truss -fp <PID>) to see what kind of system calls are being made by radius? This may give you an idea of what is going on.
Robert On Wed, Oct 06, 2004 at 01:33:34AM +0100, Stungo, Jamie wrote: > > -----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 > > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
