Laker Netman wrote:
How large a DB is this? And what type of link is
there between FR and the DB?
It's about 36 million records since april 2005.
Unless there are, literally, (tens of) thousands of
records and/or a *slow* link (think "dial-up") and/or
ancient hardware there should be some reasonable ways
to speed up the DB response. Archiving of records and
indexing are two that come to mind first. More
complicated, but effective, would be clustering or
optimization, even review of the DB version
(deprecated?).
I was partially wrong with the environment description. The
authentication DB is very small (less than 10000 records in all the
tables). It is local on Sun Netra 1120 (2x440MHz) and Oracle 9.2.0.6. It
serves about 2 to 5 radius requests per second.
And the accounting DB is located on remote server (HP DL380 3GHz,
Red Hat Enterprise with Oracle 10.2.0.1), connected to AAA server via
100BaseT link (loaded by 1-5%). The accounting process takes up to 25
requests per second. I suppose this is what bites the radius process
periodically.
Alan is correct, you are "fixing" (hiding) a symptom,
and I can say from personal experience it *will* bite
you in the butt at some point :) The worst part of
it, too, will be that the new issue may not be clearly
linkable back to the FR problem you have currently and
you may not remember this piece of the puzzle.
You are definitely right. We'll consider archiving. Indexing is already
done on all the columns taking part in "where" clauses.
Commenting rad_assert is just a temporary solution.
Just for me to spend weekend with my friends and some beer.
And not to be awaken in the night by damned SMS from dead AAA process :-)
Thanks,
--
Alexander
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
