Hi,
I'm using a FreeRadius setup (V 1.1.3-3 from Debian etch) with the MySQL Backend for authorize and accounting. RADIUS packets are coming from another company, which /probably/ has a Proxy for their delivery front-end servers. This setup usually works fine, but on some days I see spikes in the log, and the radiusd process vanishes; needing a restart.
1.1.3 (even with a few debian patches) is very very old. I would advise, if you want to stick with 1.1 train, to upgrade to 1.1.7 to fix several issues and bugs. 2.0 train - 2.0.4 would be a wiser investment of time.
I've set: max_request_time = 5 cleanup_delay = 5 max_requests = 4096 sql.conf: num_sql_socks = 256 nas: nastype = other
why did you increase the default max_requests from the defaul 1024?
Usually, there will be a few 'stop packet with zero session length' log lines, about 1 per second or fewer.
At problem/spike time, I see a lot more of these 'stop packet with zero session length' stuff (about 30 per second); and this too:
Info: The maximum number of threads (256) are active, cannot spawn new thread to handle request
this sounds like the number of requests coming in are overwhelming you SQL server - its not fast enough to keep up with realtime RADIUS accounting packets. this usually happens suddenly - either when tables get to certain size or when the number of incoming packets gets to something reasonable. so, options to make the SQL faster 1) change the engine - eg use innoDB for the SQL if you use MySQL 2) optimise and add keys etc to tables 3) stop using the DB for realtime accouting - use radsqlrelay/radrelay for 1.1 or the detail module in 2.0 - the server can then deal with realtime stuff and the accounting gets moved into 'almost real time' without affecting the server.
Is this just a very long spike (can take 10 minutes to a few hours); Are there any counters in FR that I could track? (like packets per second, etc.)
if its built with SNMP support you could always use eg RTG/MRTG to graph the counters... alan