| Subject | Re: GBak. Memory use |
|---|---|
| Author | Michael Vilhelmsen |
| Post date | 2004-11-19T07:58:10Z |
--- In firebird-support@yahoogroups.com, "Leyne, Sean" <Sean@B...> wrote:
I am pretty sure, that I have experienced the sme with 1.5.1 (but I
have to double check this).
(version 2.0) the GBak will be faster !
Or can I use it now ?
But growing from 20+ minuttes to 90+ minuttes...... ?
Besides - shouldn't the server release some memory when doing the
create index rutines (as my labtop does).
As they are on my labtop.
Also - I have just defragmented prior to running this GBak restore
operation.
As of now - I have contact with 3 different servers (1 is 2½ years
old, another is 9 months old and the last is brand new).
All of these does the same.
But as I see it, the problem will only come, when the actual size of
the DB is larger than the amount of physical memory.
Last night I did some test on some smaller DB's but the just finished
as I suspected (whcih means fast).
Michael
> Michael,FB 1.5.0
>
> > When restoring, I never comes below 300 - 400 Mbs of physical memory
> > available.
>
> What FB version you running?
I am pretty sure, that I have experienced the sme with 1.5.1 (but I
have to double check this).
>Which means, that when the next version of Firebird is released
> There was a reported problem in restoring databases with a large number
> of inter-related SP which operate on a large number of tables.
>
> I can report that GBak under v2.0 runs much faster than 1.x for both
> backup and restore.
(version 2.0) the GBak will be faster !
Or can I use it now ?
>Yes.
>
> > The server is running Windows 2000 server with a RAID system.
> >
> > I can restore this DB on the labtop within 30 minuts.
> > On the server it takes between 60 and 90 minutes!
> > It really slows down, when creating all the index.....
>
> You are aware that RAID is often not faster than IDE?
But growing from 20+ minuttes to 90+ minuttes...... ?
Besides - shouldn't the server release some memory when doing the
create index rutines (as my labtop does).
>No, they are on the same drive.
> RAID ensures reliability in the case of drive failure, but may sacrifice
> pure I/O performance to ensure that data is written correctly to all
> disks in RAID set. A good RAID controller **with Battery Backup** helps
> a lot -- by allowing for the use of 'write-through' operations.
>
> Further, is your disk defragmented on a regular basis, under Windows
> this makes a big difference. Also, do you have the temporary sort files
> (used by the index rebuilder) sorted on a different drive from the DB?
As they are on my labtop.
Also - I have just defragmented prior to running this GBak restore
operation.
As of now - I have contact with 3 different servers (1 is 2½ years
old, another is 9 months old and the last is brand new).
All of these does the same.
But as I see it, the problem will only come, when the actual size of
the DB is larger than the amount of physical memory.
Last night I did some test on some smaller DB's but the just finished
as I suspected (whcih means fast).
Michael
>
>
> Sean