What rates do you get for other non-IB processes.

E.G. normal file to and from the same disk on each.
Some kind of memory allocation de-allocation
+ a number crunching testg?

Finally, and don't shout, the NTFS partition isn't compressed is it?

Cheers,

JAC.
""csswa"" <csswa@...> wrote in message
news:a89qhs+r09v@......

> --- In ib-support@y..., "csswa" <csswa@y...> wrote:
> > sweeps of the db via gfix (no other connections) take the same
> time:
> > 16 min. Watching the server process I can see the db file being
> > walked sequencially from beginning to end at about 100k per
> second.
> > This contrasts with a backup which rips along at 1 meg per second
> > (gbak with default settings)!
>
> Hmm, the plot thickens. I copied the 100+meg db to my second
> firebird 1.0 installation: a 333mhz win95 setup with old 1 gig drive
> and 128mb ram... and the sweep ran at about 300k per second... this
> compared to my main 850mhz 512meg 20gig hd NTsp6 setup of 100k per
> second!! On the NT system I have been careful to have minimal
> processes running, no virus checker, etc. It's very strange that my
> old machine can run the sweep 3 times faster than my workhorse
> machine! The only difference I can see right now is the platform.
> I'll keep whittling away to see if I can isolate the conditions.
>
> Regards,
> Andrew Ferguson
>
>
> >
> > Gfix sweeping is a lot lighter on system resources (virtually none)
> > than gbak, though.
> >
> > Header reveals:
> >
> > Page size 4096
> > ODS version 10.0
> > Oldest transaction 287
> > Oldest active 288
> > Oldest snapshot 288
> > Next transaction 289
> >
> > So no weirdness there.
> >
> > Regards,
> > Andrew Ferguson
> >
> >
> > --- In ib-support@y..., "Ann W. Harrison" <aharrison@i...> wrote:
> > > No, sweeping and garbage collect eliminate both the record
> > > and references to it in indexes. It finds the records by
> > > walking through the tables sequentially (natural order).
> > >
> > > To remove entries from indexes, the code gets the value from
> > > the record version it's removing, checks that the values isn't
> > > used in a version of the record that's staying (reasonably cheap,
> > > unless you do something like modifying the same record 500
> > > while some transaction is open). If the value no longer applies
> > > to the record, Firebird/InterBase goes to the index and looks for
> > > the value paired with the record id. Only values propagate up in
> > > the index, so it must examine all entries in the index with that
> > > value until it finds the one with the matching record id. Here's
> > > the nasty bit. Duplicates are stored at the front of the chain,
> > > so the oldest records are last. Walking a table in natural order
> > > removes the oldest records first.
> > >
> > >
> > >
> > >
> > > Regards,
> > >
> > > Ann
> > > www.ibphoenix.com
> > > We have answers.
>
>
>
> 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/
>
>
>