aland at deployingradius.com
Wed Dec 14 09:00:02 CET 2011
amne at netconnect.ro wrote:
> All is well when there's no load but at certain times it
> happens that one of the tables must be locked for 2 or 3 seconds
One response is to use a real database. Something as critical as a
database shouldn't lock for 2-3 seconds.
> and purge on a memory table) and packets wait to be written because of the
> lock. Freeradius starts to spit warnings about packets hung in queue for
> more than x seconds then all hell breaks loose because the gateways
> retransmit these packets
Because you only have one server. Split the server into two
processes. One listens on network sockets and writes to the detail
file. It shouldn't do anything else. Another reads from the detail
file and writes to SQL.
> and it's all downhill from there. What can I do to
> make freeradius send an ok or something to the gateways as soon as the
> packets land in the detail file because once in the detail file I know for
> sure the packets will get into the database?
The problem isn't the detail file. The problem is that the server
LOCKS, because all of the threads are locked, because the DB is locked.
So it can't write to the detail file.
Splitting the server into two processes fixes that. It allows one
process to write to the detail file, even if the reader is down, or is
locked for many seconds.
More information about the Freeradius-Users