Matthew Schumacher <[EMAIL PROTECTED]> wrote: > > Log to the DB, unless the rate is too high. If it's too high, log > > to a "detail" file, and rely on an external program to feed the > > requests back in, when the rate drops. > > Where in the config would I put this logic? How could I tell radius > where to log based on load?
Source code modifications. > Machines are cheap, and I'm getting ready to do a pretty fair upgrade on > the database server, but I'm looking for a solution that won't drop > accounting messages on the floor regardless of the load. Bigger machines. The server can handle 1000's of requests per second without a problem. On a 4-way machine, I'd bet it's approaching 10K requests/s. The problem isn't the server. The problem is the back-end database, which is slow. > > A related fix would be to change src/main/threads.c, so that if an > > Accounting-Request has been sitting in the queue for more than 5 > > seconds, it's discarded and *not* processed. That should help, as the > > NAS will be re-sending the packet. > > Wouldn't sending the request back the queue if there are no DB handles > be even better? At that point, you've already partially processed it, so it would be *very* bad to re-process it from scratch. My point was that Accounting-Request packets are never retransmitted. So if a request hasn't been processed in the last 5 seconds, you're better off throwing it away, as the NAS has *already* sent you another request. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
