On Wed, 2003-01-29 at 02:11, Alan DeKok wrote:
> Matt Scifo <[EMAIL PROTECTED]> wrote:
> > I didn't even think to look in /proc.  I found the same thing.  The
> > threads were spawned according to /proc, yet the daemon is not reporting
> > thread info in the debug output.  Though that still doesn't explain the
> > horrid numbers I'm seeing.  
> 
>   The horrid numbers are due to something else blocking the server
> (back-end database, disk IO, DNS, etc)
> 

I assumed that was what the issue had to be.  Yet I have tuned and
stripped the server down to the bare minimum and am still seeing
disappointing numbers.

Let me tell you in more detail exactly how my configuration is set up so
you can get a better idea about my concerns.  As you can see from my
configuration below, I am still receiving low numbers even when I have
no back-end database, added disk IO do to writing detail records, and
hostname lookups are off.  Even with no accounting/authentication
processing, I can never get more than 60 requests per/sec, which is
disappointing on my hardware and stripped down configuration.

Hardware:  Quad Xeon 550mhz with 2g ram and 8g scsi disk
Software:  Redhat 8.0 running Freeradius 0.8.1
Network:   Full Duplex 100mb network
Configuration:  (I removed commented out sections)

######## BEGIN CONFIGURATION ##############
prefix = /usr/local
exec_prefix = ${prefix}
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = ${localstatedir}/log/radius
raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/radiusd
log_file = ${logdir}/radius.log
libdir = ${exec_prefix}/lib
pidfile = ${run_dir}/radiusd.pid
max_request_time = 30
delete_blocked_requests = no
cleanup_delay = 5
max_requests = 100000
bind_address = *
port = 0
hostname_lookups = no
allow_core_dumps = no
regular_expressions     = yes
extended_expressions    = yes
log_stripped_names = no
log_auth = no
log_auth_badpass = no
log_auth_goodpass = no
usercollide = no
lower_user = no
lower_pass = no
nospace_user = no
nospace_pass = no
checkrad = ${sbindir}/checkrad
security {
        max_attributes = 200
        reject_delay = 1
        status_server = no
}
proxy_requests  = no
$INCLUDE  ${confdir}/proxy.conf
$INCLUDE  ${confdir}/clients.conf
$INCLUDE  ${confdir}/snmp.conf
thread pool {
        start_servers = 100
        max_servers = 150
        min_spare_servers = 30
        max_spare_servers = 50
        max_requests_per_server = 0
}
modules {
        detail {
                detailfile = ${radacctdir}/detail-%Y%m%d
                detailperm = 0600
        }
        acct_unique {
                key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address,
NAS-Port-Id"
        }
        $INCLUDE  ${confdir}/sql.conf
        expr {
        }
}
instantiate {
        expr
}

## I have run tests with all of these enabled, a combination of them 
## enabled, and even with none of them enabled.
accounting {
        #acct_unique
        #detail
        #sql
}

post-auth {
}

######## END CONFIGURATION ##############



Here is debug output from one accounting request packet (with no
accounting options enabled, hence the "Nothing to do" line)...

rad_recv: Accounting-Request packet from host 66.81.1.206:46298, id=215,
length=113
Thread 33 assigned request 2362
--- Walking the entire request list ---
Thread 33 handling request 2362, (47 handled so far)
Cleaning up request 2361 ID 214 with timestamp 3e3811f9
Nothing to do.  Sleeping until we see a request.
        User-Name = "mikem"
        Service-Type = Framed-User
        NAS-IP-Address = 203.63.154.1
        NAS-Port = 1234
        NAS-Port-Type = Async
        Acct-Session-Id = "00002206"
        Acct-Status-Type = Stop
        Called-Station-Id = "123456789"
        Calling-Station-Id = "987654321"
        Acct-Delay-Time = 0
        Acct-Session-Time = 1972
        Acct-Input-Octets = 20972
        Acct-Output-Octets = 30972
Sending Accounting-Response of id 215 to 66.81.1.206:46298
Finished request 2362
Going to the next request
Thread 33 waiting to be assigned a request




Results from "top" during test shows that radiusd never uses more than
20% cpu...

 10:01am  up 22:18,  2 users,  load average: 0.05, 0.06, 0.00
94 processes: 93 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  0.1% user,  4.0% system,  0.0% nice, 94.0% idle
CPU1 states:  5.0% user,  1.0% system,  0.0% nice, 92.0% idle
CPU2 states:  2.0% user,  0.0% system,  0.0% nice, 97.0% idle
CPU3 states:  3.0% user,  0.0% system,  0.0% nice, 96.0% idle
Mem:  2064712K av,  175380K used, 1889332K free,  0K shrd, 40860K buff
Swap: 1052248K av,       0K used, 1052248K free            91536K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 3536 root      15   0  1732 1732   776 S    14.2  0.0   0:01 radiusd
<snip>



I hope I have provided enough information to be useful.  Are there any
other thoughts you can bring to light that could explain this
performance?  I would appreciate any insight you or the other members of
this list could offer.


Matt Scifo


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to