> The problem is that SuperServer is multi-threaded but not
> interlocked, so only one thread runs at a time so it cannot take
> advantage of multiple cores. Some operating systems move the process
> from one core to another in an attempt to balance load. That degrades
> performance, but can be prevented by setting the CPU affinity to a
> specific core.

Ah. I see I misunderstood the release notes completely, then: The
superserver is multithreaded, but it only applies to separate databases,
so I would need to use 2 (4) databases AND set CPU affinity to get the
benefit. Correct?

Further reading seems to indicate that Firebird can't use multiple CPU
cores for a single database in any threading mode, except for
miscellaneous tasks such as sweep. Is this also correct?

>> Again, if I increase the number to say 131072 pages (8192 bytes
>> page size, one database only) on a 2.5 GB RAM system, can I expect
>> any adverse effects?
>
> Assuming you're using a 64 bit architecture for server and operating
> system, it should help. However, the usefulness of a large cache is
> somewhat application and data dependent, so I'd try it on a test
> machine rather than launching it directly in production.

Could you please elaborate on the "assuming you're using a 64 bit
architecture" part? If I calculate correctly, 128K cache pages with 8K
page size should amount to 1G memory, which is safely withing reach of a
32bit application. Why would I need to use a 64bit system in this
scenario? Note: I am assuming a dedicated server with only one database.

Another question: I can see why a large cache fail to help performance
in some cases, but, assuming there is enough memory for the cache, can
it actually harm performance?

Thanks for your answers.

Pepak