Subject | Re: [firebird-support] Firebird configuration file(tunning firebird CS) |
---|---|
Author | Helen Borrie |
Post date | 2005-05-27T00:05:06Z |
At 07:41 PM 26/05/2005 +0200, you wrote:
parameters. However, firebird.conf isn't a tuning tool, it's a
configuration file. One parameter you should take an interest in is
CpuAffinityMask. By default, it is set to the first CPU (bitmask of
1). You should alter it to 2 if you want the fb_inet_server processes to
use either cpu01 or cpu02.
(static DbCache) per connection. With a 4Kb page size, this allocates
about 300 Kb database page cache to each connection. 512MB of RAM isn't
much to offer to 20 concurrent users and two CPUs if you set the cache too
high. 20 users will eat ~6 Mb of RAM with a 4 KB page, 12 Mb with an 8 Kb
page....and so on.
Increasing the cache will help if each user is repeatedly operating on the
same records, especially if indexes are large. But larger caches take more
RAM away from the database server and increase the likelihood that caches
and/or sorts will be relegated to memory cache on disk. Thus, the server's
ability to utilise available RAM for operations is inhibited by RAM starvation.
another. If you have seen some bench tests, we'd be glad to have the
details. :-)
Test stuff! Compare stuff! You have no startpoint for anything if you
don't do that. Study the notes in the firebird.conf file to get an idea of
what the various parameters can achieve. Some settings are specific to
Classic. Devise some tests that are pertinent to your throughput
objectives and play with config settings that look interesting. With
Classic, a changed conf will be read next time a connection is made.
./heLen
>Hello,For specific problems, that could be the case with certain configuration
>I've question about tunning Firebird classic server.
>First of all are there any publications on the internet addressing these
>issues?
>
>Secondly, I'm curious about changing parameters in firebird.conf file.
>They are many parameters like DbCacheSize etc. I assume that changing
>these parameters can boost database performance.
parameters. However, firebird.conf isn't a tuning tool, it's a
configuration file. One parameter you should take an interest in is
CpuAffinityMask. By default, it is set to the first CPU (bitmask of
1). You should alter it to 2 if you want the fb_inet_server processes to
use either cpu01 or cpu02.
>What parrameters do you use or what do you recommend for followingStay with the default settings for this server, which allocate 75 Kb pages
>configuration:
>
>-------------------
>Server details:
>-------------------
>2 Xeon HT 2.4 CPUs
>512 MB RAM
>up to 20 concurrnt connections
>database size: 4GB
>Firebird: 1.5.1 CS
(static DbCache) per connection. With a 4Kb page size, this allocates
about 300 Kb database page cache to each connection. 512MB of RAM isn't
much to offer to 20 concurrent users and two CPUs if you set the cache too
high. 20 users will eat ~6 Mb of RAM with a 4 KB page, 12 Mb with an 8 Kb
page....and so on.
Increasing the cache will help if each user is repeatedly operating on the
same records, especially if indexes are large. But larger caches take more
RAM away from the database server and increase the likelihood that caches
and/or sorts will be relegated to memory cache on disk. Thus, the server's
ability to utilise available RAM for operations is inhibited by RAM starvation.
>Server is running on 2.4 SMP kernel - i've heard that 2.6 kernel is betterI haven't heard that one kernel is "better for FirebirdCS" than
>for Firebird CS running on 2CPU (or 2Intel HT CPUs which in fact gives
>4CPUs). Is that true ?
another. If you have seen some bench tests, we'd be glad to have the
details. :-)
>Moreover are there any specific kernel settings that can boost database?What do you want to boost?
Test stuff! Compare stuff! You have no startpoint for anything if you
don't do that. Study the notes in the firebird.conf file to get an idea of
what the various parameters can achieve. Some settings are specific to
Classic. Devise some tests that are pertinent to your throughput
objectives and play with config settings that look interesting. With
Classic, a changed conf will be read next time a connection is made.
./heLen