At 09:04 PM 23/01/2006, you wrote:

> >
> > It is too long - something is wrong. Your "upgrade" was not
> > Classic-->Superserverbut v.1.0 --> v.1.5. Gbak performance should be
> > the same or better
> > under v.1.5.
>Both is right. The Upgrade is from v. 1.0 to v 1.5 and from classic to
>the superserver. If I go back to the 1.5 classicserver the backup runs
>fast again.

1.0 -> 1.5 is an upgrade. Classic <--> Superserver is a variation of
processing model. Read on...

>One machine is an IBM Server with P4 with 4GB RAM, the other machine was
>an AMD Opteron 8 GB DRR RAM.
>
> > You provided no detail about which Linux/Unix platform you are
> > running Firebird on nor how you are invoking gbak.

>The OS on the P4 was first SuSE Linux 9.3, then Debian 3.1 Sarge with
>2.6 Kernel, on the Opteron only Debian 3.1 Sarge with 2.6 Kernel.

This tells us that, in all cases, you were running kernels with the
NPTL threading. No problems for Classic, which runs each connection
as a separate process. Problems for Superserver if you are not
running the NPTL build. The non-NPTL builds expect the OS to be
using the old thread library. Therefore, to run these builds, you
need to export the LD_ASSUME_KERNEL=2.2.5 environment variable in two places.

>gbak started with "gbak -b -v"
>
>The Backup's are running every night. One time per month a validation
>and a garbage collection was done.

You are also performing garbage collection every night when you do
your backup. If you have a lot of garbage, that could account for
the extended time of the backup on SS vs Classic. Since Classic does
cooperative GC, it might well be that your databases are building up
less garbage under Classic than under SS. That's to say, background
GC under SS is run by a worker thread. Threading incompatibilities
between the server software and the OS may be inhibiting the GC
threads from starting up....

>The database looks good. No error messages.

That's good. :-)

./heLen