Subject | Re: [ib-support] IB 5.6 performance |
---|---|
Author | Jason Chapman (JAC2) |
Post date | 2002-08-07T12:41:51Z |
It's the garbage collection that is obviously causing the problem. We have
to be careful with our replication. We delete the "done" entries from the
replication, we are careful that the next replication to-do select
encompasses those deleted records so that the next backup doesn't sleep for
ages.
Obviously you could do the backup without garbage collection or I guess drop
the table (although I've never done this).
We just notched it up to experience and ensured we commit and select every
1 - 10k records or so.
They are talking about big things for IB7 (at the last Borcon), re: better
threading allowing smp machines to be better utilised. For FB, I think
after 1.5 and the new C++ code, it would be a great time to look at some of
the uglier sides of Fb/IB, such as "denial of server" when the CPU -> 100%,
fixing the optimiser. I hope that the development team swells (with an
easier build process) [including me] and we can look at some of these
issues.
JAC.
""Alan McDonald"" <alan@...> wrote in message
news:NBBBJKLIEJPCMJJOFDNPGEIMECAA.alan@......
to be careful with our replication. We delete the "done" entries from the
replication, we are careful that the next replication to-do select
encompasses those deleted records so that the next backup doesn't sleep for
ages.
Obviously you could do the backup without garbage collection or I guess drop
the table (although I've never done this).
We just notched it up to experience and ensured we commit and select every
1 - 10k records or so.
They are talking about big things for IB7 (at the last Borcon), re: better
threading allowing smp machines to be better utilised. For FB, I think
after 1.5 and the new C++ code, it would be a great time to look at some of
the uglier sides of Fb/IB, such as "denial of server" when the CPU -> 100%,
fixing the optimiser. I hope that the development team swells (with an
easier build process) [including me] and we can look at some of these
issues.
JAC.
""Alan McDonald"" <alan@...> wrote in message
news:NBBBJKLIEJPCMJJOFDNPGEIMECAA.alan@......
> just by coincidence I accidentally added about 20k records to a table themy
> other day, then deleted them (delete from table), then backed up the
> database and yep - it took an extraordinary amount of time*thought it was
> imagination). It restored in no time flat. I thought it was just a fluke,or
> me or something else but seing your post here I have to rethink it.this
> But how often would you be doing this?
> Alan
> -----Original Message-----
> From: news@... [mailto:news@...]On Behalf Of Paul
> Hope
> Sent: Wednesday, 7 August 2002 22:25
> To: ib-support@yahoogroups.com
> Subject: [ib-support] IB 5.6 performance
>
>
> Hi
>
> Up until now IB performance hasn't been a problem. But strange things
> are
> happening to a new database we are building. The import routine creates
> about 260,000 records in one table.
>
> Having done it I want to delete all the record and start again.
> If I do 'delete from table' followed by a 'select * from table' I would
> expect the latter to take some time because (I believe) it is doing
> garbage
> collection - however I wouldn't expect it to take several hours :-(
>
> Last night I did a 'delete from table' then a backup and restore. The
> backup took 5.5 hours - the restore took 3 minutes!
>
> The server isn't particularly fast (maybe a 300Mhz) but we havn't had
> sort of time problem before. The processor is runing at 100% and Idon't
> understand what the memory utilisation is telling me, there looks like
> plenty of free disk space.
>
> Running NT4 sp6a
>
> Could there be an IB problem I can look at - if so where do I look?
>
> Regards
> Paul
>