Freeradius performance settings or bug?
Hi, I'm seeing some odd behavior running freeradius-1.1.7 in a freebsd 6.3 environment. I see a lot of these in the radius log: Tue Apr 22 09:27:44 2008 : Error: Discarding duplicate request from client arc3.wnskvtao.sover.net:1645 - ID: 208 due to unfinished request 1267 Tue Apr 22 09:27:44 2008 : Error: Discarding duplicate request from client arc3.wnskvtao.sover.net:1645 - ID: 209 due to unfinished request 1268 as well as the cputime constantly increasing the longer I leave radiusd running: last pid: 34247; load averages: 0.29, 0.32, 0.39 up 4+22:29:48 09:27:05 30 processes: 2 running, 28 sleeping CPU states: 2.6% user, 0.0% nice, 10.5% system, 0.0% interrupt, 86.8% idle Mem: 17M Active, 447M Inact, 173M Wired, 20K Cache, 112M Buf, 2618M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 34011 root 20 0 9852K 6904K kserel 2 8:09 1.61% radiusd 34011 root 96 0 9852K 6904K select 0 8:09 0.00% radiusd 34011 root 20 0 9852K 6904K kserel 2 8:09 0.00% radiusd 34011 root 20 0 9852K 6904K kserel 2 8:09 0.00% radiusd 34011 root 20 0 9852K 6904K ksesig 0 8:09 0.00% radiusd 34011 root 98 0 9852K 6904K CPU0 0 8:09 0.00% radiusd Looking at older messages posted to the list, I see Alan suggests that the duplicate requests are related to radiusd not replying quickly enough due to either having hostname lookups enabled or due to sql backend slowness. I'm not using sql in my configuration and do not have hostname lookups enabled. Are there any settings I could tweak in radiusd.conf to help? Maybe there is a bug I am not aware of relating to running freeradius under freebsd (I know there are some SMP related issues). Here are some configuration snippets that may be relevant: cleanup_delay = 2 max_requests = 10240 hostname_lookups = no thread pool { start_servers = 20 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } Any help or suggestions would be greatly appreciated. Jeremiah
Jeremiah Millay wrote:
Hi, I'm seeing some odd behavior running freeradius-1.1.7 in a freebsd 6.3 environment. I see a lot of these in the radius log:
Tue Apr 22 09:27:44 2008 : Error: Discarding duplicate request from client arc3.wnskvtao.sover.net:1645 - ID: 208 due to unfinished request 1267 Tue Apr 22 09:27:44 2008 : Error: Discarding duplicate request from client arc3.wnskvtao.sover.net:1645 - ID: 209 due to unfinished request 1268
as well as the cputime constantly increasing the longer I leave radiusd running:
Well yes; the process runs, and accumulates CPU time. What OS is this?
Looking at older messages posted to the list, I see Alan suggests that the duplicate requests are related to radiusd not replying quickly enough due to either having hostname lookups enabled or due to sql backend slowness. I'm not using sql in my configuration and do not have hostname lookups enabled.
Are you using "wtmp" i.e. "radlast". Don't. It's slow.
Here are some configuration snippets that may be relevant:
cleanup_delay = 2 max_requests = 10240 hostname_lookups = no thread pool { start_servers = 20 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 }
That looks OK as a first cut. What's the full config?
Phil Mayers wrote:
Jeremiah Millay wrote:
Hi, I'm seeing some odd behavior running freeradius-1.1.7 in a freebsd 6.3 environment. I see a lot of these in the radius log:
Tue Apr 22 09:27:44 2008 : Error: Discarding duplicate request from client arc3.wnskvtao.sover.net:1645 - ID: 208 due to unfinished request 1267 Tue Apr 22 09:27:44 2008 : Error: Discarding duplicate request from client arc3.wnskvtao.sover.net:1645 - ID: 209 due to unfinished request 1268
as well as the cputime constantly increasing the longer I leave radiusd running:
Well yes; the process runs, and accumulates CPU time.
Sorry, that was dumb of me.
What OS is this? FreeBSD 6.3-p2 ( I applied a patch to p1 which fixed a bug in libthread which seemed to help out cpu utilization significantly). Still seeing these duplicate request errors however.
Looking at older messages posted to the list, I see Alan suggests that the duplicate requests are related to radiusd not replying quickly enough due to either having hostname lookups enabled or due to sql backend slowness. I'm not using sql in my configuration and do not have hostname lookups enabled.
Are you using "wtmp" i.e. "radlast". Don't. It's slow.
Here are some more snippets related to wtmp (from what I can tell): unix { cache = no cache_reload = 600 radwtmp = ${logdir}/radwtmp } accounting { detail unix radutmp } session { radutmp } I'm guessing it won't harm anything to remove the radwtmp line from the unix configuration. Correct? I suppose its also ok to remove unix and radutmp from the accounting section? Thanks so much for your suggestions. I think you are on to something! Let me know if you want me to send you the whole config... (I'll need to clean it up first). Jeremiah
Here are some configuration snippets that may be relevant:
cleanup_delay = 2 max_requests = 10240 hostname_lookups = no thread pool { start_servers = 20 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 }
That looks OK as a first cut. What's the full config? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Are you using "wtmp" i.e. "radlast". Don't. It's slow.
Here are some more snippets related to wtmp (from what I can tell):
unix { cache = no cache_reload = 600 radwtmp = ${logdir}/radwtmp } accounting { detail unix radutmp }
session { radutmp }
I'm guessing it won't harm anything to remove the radwtmp line from the unix configuration. Correct? I suppose its also ok to remove unix and radutmp from the accounting section?
If you're not using those, do indeed remove them. utmp/wtmp is slow to update, especially if the files are large.
Jeremiah Millay wrote:
I'm seeing some odd behavior running freeradius-1.1.7 in a freebsd 6.3 environment. I see a lot of these in the radius log:
Tue Apr 22 09:27:44 2008 : Error: Discarding duplicate request from client arc3.wnskvtao.sover.net:1645 - ID: 208 due to unfinished request 1267
Find out what's blocking the server.
Here are some configuration snippets that may be relevant:
cleanup_delay = 2 max_requests = 10240
That's a very low cleanup_delay, but it shouldn't cause this problem.
hostname_lookups = no thread pool { start_servers = 20 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 }
Any help or suggestions would be greatly appreciated.
Upgrade to 2.0.3. :) Alan DeKok.
participants (3)
-
Alan DeKok -
Jeremiah Millay -
Phil Mayers