Subject | Re: [IBO] Big Batch... |
---|---|
Author | Frank Ingermann |
Post date | 2001-03-19T20:34:19Z |
Hi Paul,
Paul Schmidt wrote:
some select, IB's CPU usage pops up to 100% (for some time). NT's "smart"
multi-cpu-handler sees: "hey, there's one cpu on a 100%, the other at 5%. We'll
go and put IB on the second CPU to balance the load!" (not knowing that IB will
always definitely make use of only *one* cpu). said & done.
Some millisecs later: NT: "Hey, cpu 2 is overloaded! let's switch back to
cpu 1!" (... you can guess the rest: NT is practically locked because it is
spending all of its time moving IB from one cpu to the other & back again...
and IB itself doesn't even get the few machine cycles to complete its job...)
however, there is a cure for this: take IBAffinity (by Karsten Strobel) from
either www.ait-augsburg.de or ibobjects.com. This little tool modifies the
"affinity mask" of the IBServer process in such a way that IB will be *bound*
to one cpu, preventing NT from doing it's "cpu juggling".
the good news is that with this fix applied, IB will indeed perform better
on a dual-cpu machine, because NT can do all it's internal stuff on the first
while IB exclusively uses the second. Moreover, should the IB process ever
crash completely, NT will still be available to shoot it down & restart it.
hth,
fingerman
Paul Schmidt wrote:
>in short terms: you start IB under NT with 2 CPUs. IB runs on CPU 1. You make
> Hie Joen (and others):
>
> Could someone tell me why a machine with multiple processors (2 or
> more) would run IB more slowly?
some select, IB's CPU usage pops up to 100% (for some time). NT's "smart"
multi-cpu-handler sees: "hey, there's one cpu on a 100%, the other at 5%. We'll
go and put IB on the second CPU to balance the load!" (not knowing that IB will
always definitely make use of only *one* cpu). said & done.
Some millisecs later: NT: "Hey, cpu 2 is overloaded! let's switch back to
cpu 1!" (... you can guess the rest: NT is practically locked because it is
spending all of its time moving IB from one cpu to the other & back again...
and IB itself doesn't even get the few machine cycles to complete its job...)
however, there is a cure for this: take IBAffinity (by Karsten Strobel) from
either www.ait-augsburg.de or ibobjects.com. This little tool modifies the
"affinity mask" of the IBServer process in such a way that IB will be *bound*
to one cpu, preventing NT from doing it's "cpu juggling".
the good news is that with this fix applied, IB will indeed perform better
on a dual-cpu machine, because NT can do all it's internal stuff on the first
while IB exclusively uses the second. Moreover, should the IB process ever
crash completely, NT will still be available to shoot it down & restart it.
hth,
fingerman