>> 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?

Correct.

This information is a bit hidden but there in the following Firebird 2.5
architecture comparison sheet:
http://www.firebirdsql.org/file/fb25_architecture_comparison.pdf

> 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?

No. SuperClassic and Classic can take advantage of multiple cores for a
single database.

The following screencast might be helpful:
http://www.iblogmanager.com/download/demos/firebird/fb25_architectures_smp.html



--
With regards,
Thomas Steinmaurer
http://www.upscene.com/

>>> 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
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>