At 02:42 PM 2/03/2006, you wrote:

> > No. It's exactly the same for Firebird Superserver. A 32-bit
> > process is a 32-bit process. However, the cure for Firebird has
> > another option - use Classic.
>
>I must admit I had not considered this option. Having little
>experience with Classic (just installed now on my laptop), what are
>the gotchas I need to know about? I know I may need to disable
>Guardian.

You MUST disable Guardian.

>I have read the release notes and nothing stands out. The
>absence of local connection is fine, it doesn't work under terminal
>server anyway.
>
>Will I need to adjust the default conf file settings or will the
>default values be sensible?

The default 2048 cache pages ought to be for Superserver only. Since
the advent of firebird.conf, I have no idea whether Classic is built
with the default 75 pages so, to be on the safe side, I explicitly
configure it in 1.5. 75 pages is probably a bit low for a 4Kb
page: try 256. But certainly not 2048. And don't ramp up VM to
take care of a larger cache. A cache that has to pag out is worse
than not having it.

You're going to have one lockmanager subsystem going for each
database. So read up Ann's article in IBDeveloper mag #3 for some
tips about configuring lock manager's bits 'n' bobs. The lock tables
*can* pag out but, again, you don't want to have the situation where
most of the writes to the lock tables are happening on disk. Make
sure there's plenty of RAM available.

You still have a process limit of 2 Gb addressable memory but now it
is *per connection*. So make sure that the overall resources are
plentiful. If you have other things competing with your database
server for RAM, you'll really notice the effects of resource
starvation. I've seen people here complaining that Classic was too
slow for them; never mind that they were running webservers, web
applications, screensavers, Windows itself, the network services,
anti-virus monitors, Microsoft Exchange....you name it, the whole
junkshop on one machine.

That's why I mentioned the Linux box. You don't need all that rat's
nest on a database server. You can set up a Linux box bare-bones as
a dedicated database server for very little. Heck, every time I
upgrade some hardware on my Windows brutes, I conserve all the
hardware to repackage as little Linux servers. Cost is zilch, or
near it, and it's a brilliant way to make use of those boxes of
obsolete ram that are otherwise gathering dust. Get the boss to stop
taking the superseded hardware home for his kids: let it work for a
living. :-)

>More information on the first server, I discovered it only had a tiny
>amount of VM (300MB). Given that the server only has 1.25GB RAM, I
>have advised them to increase it.
>
>The second server has about twice that much RAM, enough VM and less
>active users so I am a little confused about that one.

Well, the Superserver can still only address 2 Gb in toto.

Now I gotta do some work.

./heLen