Subject | RE: [ib-support] ibserver running at 100% |
---|---|
Author | Wilson, Fred |
Post date | 2002-09-11T16:05:11Z |
Helen, FWIW, we've had the CPU go to 100% on little queries (way back in the
"early" days), when we had huge transaction gaps (over 1 million !!) ... But
on gaps, like shown below, no, I haven't seen any outwardly extra CPU usage.
Best regards,
Fred Wilson
SE, Bell & Howell
fred.wilson@...
-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Wednesday, September 11, 2002 8:42 AM
To: ib-support@yahoogroups.com
Subject: RE: [ib-support] ibserver running at 100%
At 05:01 PM 11-09-02 +0200, you wrote:
(1) selects a set and holds it open all day
(2) uses CommitRetaining and never hard-commits the transaction
(3) crashes with a bunch of uncommitted work
An environment where
(1) DDL is performed on a database while users are active
(2) users run a lot of apps simultaneously and keep uncommitted work lying
around hidden in task-bar icons
(3) auto sweeping is disabled and nobody runs manual sweeps
(4) gbak is rarely or never run
(5) users "log out" by hitting the "off" switch
(6) a reporting app is running huge reports to an overloaded printer queue
Still 'n' all, lack of OIT movement shouldn't affect CPU usage, even though
it will eventually kill the server.
Is your server XP and by chance an unknowing victim of SystemRestore or
some other background Microsoft invention targeted at gdb files?
Are you sure ibserver is eating the whole pie?
heLen
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/
"early" days), when we had huge transaction gaps (over 1 million !!) ... But
on gaps, like shown below, no, I haven't seen any outwardly extra CPU usage.
Best regards,
Fred Wilson
SE, Bell & Howell
fred.wilson@...
-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Wednesday, September 11, 2002 8:42 AM
To: ib-support@yahoogroups.com
Subject: RE: [ib-support] ibserver running at 100%
At 05:01 PM 11-09-02 +0200, you wrote:
> > > > What is the information regarding the transactions that is returnedby
> > >GSTAT?transactions
> > > Generation 92098
> > > Oldest transaction 77749
> > > Oldest active 77750
> > > Oldest snapshot 77724
> > > Next transaction 92088
> > I that the difference between Oldest Active and Next Transaction is
> > wide. Usually, a backup and restore brings them closer.
>the problem is that this database does about 200000 transactions a day. i
>have investigated this problem further and i found out that the
>are moving for some time and then suddendly stop moving. when thedifference
>between the oldest and the next trx becomes too great the problem arises.could
>restarting the server from time works but it can't stay this way. what
>cause the trx numbers not to move forward?An application that
(1) selects a set and holds it open all day
(2) uses CommitRetaining and never hard-commits the transaction
(3) crashes with a bunch of uncommitted work
An environment where
(1) DDL is performed on a database while users are active
(2) users run a lot of apps simultaneously and keep uncommitted work lying
around hidden in task-bar icons
(3) auto sweeping is disabled and nobody runs manual sweeps
(4) gbak is rarely or never run
(5) users "log out" by hitting the "off" switch
(6) a reporting app is running huge reports to an overloaded printer queue
Still 'n' all, lack of OIT movement shouldn't affect CPU usage, even though
it will eventually kill the server.
Is your server XP and by chance an unknowing victim of SystemRestore or
some other background Microsoft invention targeted at gdb files?
Are you sure ibserver is eating the whole pie?
heLen
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/