Re: [RadiusNT] Status of our question????

Mike Miller ( )
Sun, 14 Mar 1999 13:18:50 -0500

At 10:11 AM 3/14/99 -0800, you wrote:
>Mike Miller wrote:
>> I think (but am not positive yet) that we have the concurrency problems
>> under control. We moved Radius onto a different machine than the SQL
>> server and the concurrency problems seem to have gone away??? Even still
>> we have problems with insert queries locking the calls table if we shut
>> down Radius. It appears however, that these locks do go away with a reboot
>> of the SQL machine (unlike when Radius was on the same machine as SQL and
>> the locks would still be there). The problem is fully reproducible.. and
>> makes no sense that moving Radius to a machine other than the SQL box
>> changed the problems in such a strange way. Has the RadiusNT/SQL 7 combo
>> been tested in a multi-processor capable environment? I ask because our
>> SQL box was showing long spikes of 100% CPU usage when Radius was running
>> on the same box (we discovered this this morning). Radius debug was not
>> showing slow response times despite the spikes in CPU usage.
>A lock shouldn't survive a reboot, AFAIK. The original install was on a
>Quad PII-400 Xeon box, and I do remember seeing the CPU spike problem,
>even though RadiusNT was not installed on the machine at the time.
>When you moved RadiusNT off the box, the spiked went away?

They have not completely "gone away", but have definitely improved! When
RadiusNT was on the same box, the CPU spikes would last for several minutes
only to allow a couple seconds of normal activity. Now that RadiusNT is on
a different box, the CPU spikes are still occurring (really odd), but they
only last for a couple seconds at most followed by about 10-20 seconds of
normal activity.

>> To answer your question... we have tried this on a fresh install of NT,
>> SP4, and SQL 7 on this same machine, but we have not tried it on other
>> hardware. I would agree with you about the possibility of a SQL install
>> problem, but... at the moment all fingers are pointed at Radius (the
>> processes causing locks are started by Radius, and Radius don't seem to
>> like running on the same box as SQL 7)
>I don't have a lot of test information with RadiusNT running on the
>same machine as SQL in a multiprocessor enviroment. I use a PII-300
>laptop with SQL 7 and RadiusNT on the same machine for testing.
>My test server is a PII-300 single proc as well.
>> Taking questions one at a time... how does Radius/SQL handle it, when
>> Radius is shut down (what is causing our calls table to get locked)? How
>I added some code to actually stop and and disconnect all connections
>in the next update. However, I've never seen RadiusNT cause the
>you are reporting. This may be a new issue with SQL7 that we simply
>haven't uncovered yet. The only thing that can cause the table to be
>locked is either an insert or update (something to change it). RadiusNT
>only does inserts to the table. I suppose in theory that if RadiusNT
>sent the insert w/out closing the query when it was stopped that the
>last page of the calls table could be locked, but I have never seen

I know you love to hear this question asked, but when will the next version
be available to the public?

>> (if any) does this differ from connecting to a SQL 6.5 database? We are
>RadiusNT doesn't know the difference between the two.
>> using a system DSN via TCP/IP sockets to connect Radius to the SQL
>> database. The hardware our SQL server is using is PII-333, 256MB RAM. The
>> data portion of our database size is about 600MB on a properly populated
>> Calls table (but is much smaller now because we have dropped our calls
>> accounting history during these problems). If we can get these questions
>> about why Radius is causing locks in our calls table, then we can take the
>> appropriate steps to stop it from happening.
>What you'll probably have to do is enable ODBC/SQL trace and then
>start/stop RadiusNT to create the lock and look at the trace to see
>where RadiusNT left the connection.
>> Further data:
>> ODBC version on system where Radius
>> concurrency works: 3.50.0305
>> (Locks on Calls table from this Radius can be cleared
>> with a reboot of the SQL box)
>> ODBC version on system where Radius concurrency
>> doesn't work (SQL 7 box):
>> (Locks on Calls table from this Radius can not be cleared
>> with a reboot of the SQL box)
>The other thing is this could be and ODBC issue. What version of the
>SQL ODBC driver is on the other machine (not running SQL 7). Maybe
>this is an issue with the SQL 7.0 ODBC driver?

This could be an ODBC driver issue.. as you can see above, Radius is much
happier on the outside NT box that is running the 3.50.0305 driver than it
is residing on the As I recall we also had to fight a
malformed packet problem when we first installed it on the SQL 7 box
running that does not exist on the older ODBC driver.

Right now I am spending the weekend trying to build another SQL7 box to
test on. I'll let you know the results.

>Dale E. Reed Jr. Emerald and RadiusNT
>IEA Software, Inc.
>For more information about this list, including removal, please
>see this URL:
= /\ Mike A. Miller =
= /--\ \/ Abraxis Networks =
=/ \ B R A /\ I S =
= / =
= N E T W O R K S

For more information about this list, including removal, please
see this URL: