On Wed, May 16, 2012 at 1:53 PM, Alan DeKok <aland@deployingradius.com> wrote:
The solution is to split the DB into two pools. One for accounting (read/write), and another for authentication (read-only). You can provision 50 sockets for acct && auth, then 100 threads. After that, a blocked accounting DB will have *no* effect on authentication.
Interesting idea. So use the number of db threads to somewhat limit max number of server threads used for accounting? In our implementation we ended up going with decoupled accounting instead, which pretty much serialize accounting load to db to the number of detail file and reader.
On top of that, the server prioritizes authentication internally. It will preferentially process authentication packets over accounting packets. So that's one more way to avoid server meltdown.
Is this code new? I haven't seen that effect back on our old setup (the days of FR-2.1.7). But then again there might be other factors causing it. -- Fajar