Subject | Re: [ib-support] Threads in IB 5.6 |
---|---|
Author | Jason Chapman (JAC2) |
Post date | 2003-01-20T09:32:18Z |
They did some very specific load testing and found that 2 processors out
performed a single processor. When the single processor started to choke,
the threads in the IB process increased very quickly (from 20 -> 200+). I
am pretty sure now that this is either the Winsock or OS Disk IO layer (i
would put money on the network side). Unfortunately they are putting a
second processor in and if it fixes it, there will be no more research.
Their App is BDE, so when they have a couple of hundred users on
concurrently there is a lot of TX start / commit and a lot of little
queries. Combine this with continual tablescan queries from large searches
on tables with 1,000,000+ rows (which are executing in half the time).
My conclusion is that now that the disks are faster (twice as fast), they
are less of a bottleneck. This is leading to the processor being more
heavily loaded (per second), because the processor is responsible for
processing both the long disk intensive queries and the short client
queries, it is having less cycles per second to deal with the short client
queries, so lets say before it was:
10% CPU cyles long reporting queries 90% short client queries
now it is 40% CPU cycles on long reporting queries 60% short client queries.
They put in another processor on Sunday, I'll keep you posted.
Cheers,
JAC.
""Martijn Tonies"" <m.tonies@...> wrote in message
news:019401c2c056$a05aa250$0a02a8c0@seal...
performed a single processor. When the single processor started to choke,
the threads in the IB process increased very quickly (from 20 -> 200+). I
am pretty sure now that this is either the Winsock or OS Disk IO layer (i
would put money on the network side). Unfortunately they are putting a
second processor in and if it fixes it, there will be no more research.
Their App is BDE, so when they have a couple of hundred users on
concurrently there is a lot of TX start / commit and a lot of little
queries. Combine this with continual tablescan queries from large searches
on tables with 1,000,000+ rows (which are executing in half the time).
My conclusion is that now that the disks are faster (twice as fast), they
are less of a bottleneck. This is leading to the processor being more
heavily loaded (per second), because the processor is responsible for
processing both the long disk intensive queries and the short client
queries, it is having less cycles per second to deal with the short client
queries, so lets say before it was:
10% CPU cyles long reporting queries 90% short client queries
now it is 40% CPU cycles on long reporting queries 60% short client queries.
They put in another processor on Sunday, I'll keep you posted.
Cheers,
JAC.
""Martijn Tonies"" <m.tonies@...> wrote in message
news:019401c2c056$a05aa250$0a02a8c0@seal...
> Hi Jason,are
>
> > Sorry you got lumbered with the "everything must be free otherwise you
> > the anti-Christ" flame, very tolerant of you, I think I would have beenfresh
> less
> > humane.
>
> Ah well - worse things happen at sea... I tried doing my best to help
> the guy.
>
> But, anymore news yet?
>
> --
> Martijn
>
> > The live server is running BDE apps and replication, so the TX diffs can
> get
> > pretty high, but the test servers that exhibit the same are run from
> > and exhibit the performance differences after just a few minutes, so I'm
> > guessing not. As I said, I haven't been on site, so I haven't been able
> to
> > have a very good look, hoping to do that on Friday.
> >
> > I was hoping to pick up a couple of gems like:
> > A new thread is spawned when a client is waiting for a query to be
> executed
> > or when the server is waiting to send results back. Because of the home
> > grown threading in 5.6 I am assuming that threads are implemented on the
> > periphery, e.g. server side remote connection handler, rather than low
> level
> > VIO / Execution / Planning etc.
> >
> > They have been running on the old server for years, running hot mind as
> the
> > load is pretty heavy and it is BDE.
> >
> > I'll do some more digging on Friday, but any help on why, how and when
> > threads are created / destroyed in IB would be of help.
> >
> > Cheers,
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>