In using the new DeleteQuery that 'or' in the statement can really put a
severe strain on a loaded database (even with indexes turned on.) My one
server went from a load of .05 to around 1.09 in a short time. I also had
a ton of locked processes waiting for queries to finish. I have a patch
that creates a new var called DeleteIPQuery. This just runs a separate
query right before a user is put into the online database. This seems to
be much less stressful on my database than the combined query.... Just my
two cents. Feel free to email me if you'd like the patch to the 2.16.1
source. However, this same patch was applied to 2.14.1 as well, so it is
pretty backwards compatible and isn't very big....
--------------------------------------------------------------------------
Aaron Holtz
ComNet Inc.
UNIX Systems Administration/Network Operations
"It's not broken, it just lacks duct tape."
--------------------------------------------------------------------------
On Jun 15, Mike McCauley molded the electrons to say....
>On Jun 15, 8:33am, Hugh Irvine wrote:
>> Subject: Re: (RADIATOR) Sim. use control by Ping
>>
>> Hello Clement -
>>
>> On Wed, 14 Jun 2000, Clement wrote:
>> > Hi Mike and Hugh,
>> >
>> > Thank you very much for the new feature. Most of the time, it works
>> > well. However, we just come into a situation when the old IP was
>> > reallocated and the PING test just failed to tell.
>> >
>> > I think the solution is simple. Before writing a new session record,
>> > remove any existing one with the same IP address. This should be true
>> > in all situations. An IP address just cannot be used by 2 or more
>> > connections at the same time. For session data base using SQL, which we
>> > are, it may need only one SQL statement like this to do the job.
>> >
>> > delete * from RADONLINE where FRAMEDIPADDRESS = 'new.ip.addr';
>> >
>> > Can you gentlemen make the change? I think it can be a 2 minute job for
>> > you experts.
>>
>> This is exactly what one of our other customers has done - he added a
>> "DeleteIPQuery" to the session database. We haven't yet included this in
>> Radiator because we are concerned about the potential for the session
>database
>> to become corrupted in some circumstances.
>>
>> I've forwarded your thoughts to Mike.
>The DeleteQuery gets run just before adding a new session. I wonder if the
>right thing is to alter the DeleteQuery so it deletes the IP address too:
>
>DeleteQuery delete from RADONLINE where (NASIDENTIFIER='%N' and
>NASPORT=0%{NAS-Port}) or FRAMEDIPADDRESS = '%{Framed-IP-Address}'
>
>Thoughts?
>
>Cheers.
>
>>
>> many thanks for your contributions
>>
>> regards
>>
>> Hugh
>>
>> --
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>> Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
>> Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
>>
>>
>>
>>-- End of excerpt from Hugh Irvine
>
>
>
>--
>Mike McCauley [EMAIL PROTECTED]
>Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
>24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
>Phone +61 3 9598-0985 Fax +61 3 9598-0955
>
>Radiator: the most portable, flexible and configurable RADIUS server
>anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
>on Unix, Win95/8, 2000, NT, MacOS X
>===
>Archive at http://www.starport.net/~radiator/
>Announcements on [EMAIL PROTECTED]
>To unsubscribe, email '[EMAIL PROTECTED]' with
>'unsubscribe radiator' in the body of the message.
>
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
