Subject Fwd: Last 256 Sockets on NT
Author Helen Borrie
Olivier,
I'm forwarding this to save Charlie from reposting it. :)
Helen


>Date: Tue, 27 Jun 2000 09:38:24 -0700
>From: "Charlie Caro" <ccaro@...>
>To: interbase@...
>Subject: Re: Threads on NT
>
>Andre,
>
>You are going to have to reduce your TCP/IP connections to your InterBase
>V5.6/NT server below 256. InterBase/NT only selects messages from sockets for
>the last 256 connections. You need to up the Midas ratio of actual
>clients/actual connections to about 7 or 8:1 for 1500 clients to keep the
>connections below 256.
>
>We haven't fixed this for IBV6 but I expect we can achieve a quick
>consensus on
>the architecture list to up it from 256 to 1024+ for a V6.1 point release. If
>you don't want to wait, you will have the open source to make your own change.
>I'm sorry but there's no config parameter to modify this behavior in IBV5.6.
>
>The 100% CPU could be a: 1) database sweep, 2) garbage collection of long
>duplicate index chains, or 3) long record back version chains. These three
>areas
>have been addressed in IBV6 but future work could improve 2) and 3) even more.
>
>Since the first 19 connections (275 - 256) are not listened to, they cannot
>commit transactions. This can cause long record chains, stall other concurrent
>transactions modifying the same records. It even makes it impossible for the
>InterBase server to notice when they disconnect. The server won't see their
>network messages until some of the later connections detach and make the
>connection list fall below 256. Since you are using Midas to maintain a shared
>pool of connections, it may never fall below that limit (consult Midas
>documentation).
>
>Regards,
> Charlie
>
>Andre Mostert wrote:
> >
> > Greetings
> >
> > Can anybody shed some light on threads under NT ie the threads spawned by
> > Interbase.
> >
> > Some Background ..
> >
> > We have a Debtors/Membership system written in Delphi talking to a
> Interbase
> > 5.6 database on NT 4.0 (SP5). The application itself is a n-tier
> (Delphi 3 /
> > Midas). The server is a dual 700 mhz machine with 2 gigs of memory and
> some
> > 20 gigs of diskspace. We have set IB to run realtime with its affinity set
> > to processor 1. Where possible we have set all other processes to run on
> > processor 0. The Db is 800 meg at this stage.
> >
> > We started to notice a slowdown on the app when the server reached
> > approxiamately 275 concurrent connections (We have potentially 1000 - 1500
> > users). The performance monitor seemed to indicate that Interbase was doing
> > very little and for the most part of it the server was as close to idle as
> > one can get. This seemed to indicate a bottle neck of sorts.
> Local ISQL had
> > no trouble connecting at this stage and IBServer reponses were almost
> > instantanteous. We placed various sniffers, monitors in place which
> did not
> > really reveal anything significant. After consultation with Microsoft we
> > decided to add another network card (Thinking that perhaps the TCP/IP stack
> > was perhaps the bottleneck.). The server now has 2 IP addresses and we
> > logically partitioned our users across the two addresses.
> >
> > Unfortunately this second card's installation coincided with the
> delivery of
> > a new build and metadata changes from our software house. (I know this is
> > not ideal)
> >
> > The Problem ..
> >
> > Not long after the deployment of the new app and application servers we
> > noticed that the server often had periods when processor 1 and IBServer ran
> > at 100%. Using the NT performance monitor I added all IB threads that
> > belonged to IBServer
> > and found that whilst roughly 15 threads were being spawned it was
> typically
> > only 1 thread that running at 100% when IBserver was.
> >
> > Questions ..
> >
> > a) How are these threads spawned and exacly what are they doing. eg. If a
> > user fires a stored procedure does it spawn a thread that terminates once
> > completed.
> >
> > b) In the senario of one thread running at 100% in conjunction with
> IBServer
> > , could it perhaps be one stored proc that is not behaving.
> >
> > Thanks
> >
> > Regards Andre
> >
>
>_______________________________________________
>Interbase mailing list
>Interbase@...
>http://mers.com/mailman/listinfo/interbase

http://www.interbase2000.org
___________________________________________________
"Ask not what your free, open-source database can do for you,
but what you can do for your free, open-source database."
(J.F.K.)