Subject | AW: AW: [firebird-support] Problem Firebird Classic Server |
---|---|
Author | Olaf Kluge |
Post date | 2008-06-11T09:29:08Z |
Hello Anderson, Helen and Fabian,
now I'm confused.
First my gstat -h statistics:
Flags: 0
Checksum 12345
Generation 230320
Page Size 4096
ODS version 11.0
Oldest transaction 833
Oldest active 961
Oldest snapshot 840
Next transaction 229603
Bumped transaction 1
Sequence number 0
Next attached ID 711
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation Date Jun 6, 2008 10:31:39
Attributes
Sweep interval: 20000
The server has 4 GB of RAM.
Firebird.conf: #DefaultDbCachePages = 2048 - I don't have changed at the
time
I have read all your responses.
It is right, that I change the firebird.conf - value #DefaultDbCachePages =
2048 to DefaultDbCachePages = 75 ? or better 128?
I have three suggestions and different values. Shall I change also the Page
Size?
Are the many error-messages a result of the wrong values? (FLS (Client) Thu
Dec 06 08:41:50 2007
INET/inet_error: connect errno = 10060)
I am unsure about at the moment because there are different opinions.
Thanks a lot for your help.
At 12:38 AM 11/06/2008, you wrote:
The maximum page size possible is 16 Kb. And the processes actually use RAM
for lots of things *other than* cache so your calculations are meaningless.
For example, each connection uses about 1.7 Mb of server RAM just to exist.
And we haven't even started on the RAM that each instance of the server uses
to service the client requests!
Furthermore, huge caches can impair performance severely, since they will
spend most of their life being paged back and forth to disk and totally
defeat their purpose.
Olaf, please read my posting again and take note what I said about the cache
size (also referred to as buffers or page buffers). It is a number expressed
in pages. SHOW DATABASE in isql will report it, as will a gstat -h command.
Some third-party tools also report it in database attributes.
The numbers I quoted (between 128 and 256 pages of cache) should be optimal
for a 4 Kb page size and 60 users, with a reasonable amount of RAM. Begin
with the lower number of pages (128), particularly if you have many queries
that use sorting (ORDER BY or GROUP BY).
./heLen
[Non-text portions of this message have been removed]
now I'm confused.
First my gstat -h statistics:
Flags: 0
Checksum 12345
Generation 230320
Page Size 4096
ODS version 11.0
Oldest transaction 833
Oldest active 961
Oldest snapshot 840
Next transaction 229603
Bumped transaction 1
Sequence number 0
Next attached ID 711
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation Date Jun 6, 2008 10:31:39
Attributes
Sweep interval: 20000
The server has 4 GB of RAM.
Firebird.conf: #DefaultDbCachePages = 2048 - I don't have changed at the
time
I have read all your responses.
It is right, that I change the firebird.conf - value #DefaultDbCachePages =
2048 to DefaultDbCachePages = 75 ? or better 128?
I have three suggestions and different values. Shall I change also the Page
Size?
Are the many error-messages a result of the wrong values? (FLS (Client) Thu
Dec 06 08:41:50 2007
INET/inet_error: connect errno = 10060)
I am unsure about at the moment because there are different opinions.
Thanks a lot for your help.
At 12:38 AM 11/06/2008, you wrote:
>Hi Olaf,No, Fabian, sorry, this is not correct.
>
>In Classic each user/connection consumes (Page Size * Buffer size), so you
>need to reduce it based on your max simultaneous connections and available
>memory.
>Let's say you have 70 users max, and 2 Gb Ram, then 2000Mb / 70 = 28 Mb
>each, if pagesize is 4mb then you can have a cache of 7 pages (7 * 4 = 28).
>
>There are other small considerations to take into account, but in principle
>the above is correct.
The maximum page size possible is 16 Kb. And the processes actually use RAM
for lots of things *other than* cache so your calculations are meaningless.
For example, each connection uses about 1.7 Mb of server RAM just to exist.
And we haven't even started on the RAM that each instance of the server uses
to service the client requests!
Furthermore, huge caches can impair performance severely, since they will
spend most of their life being paged back and forth to disk and totally
defeat their purpose.
Olaf, please read my posting again and take note what I said about the cache
size (also referred to as buffers or page buffers). It is a number expressed
in pages. SHOW DATABASE in isql will report it, as will a gstat -h command.
Some third-party tools also report it in database attributes.
The numbers I quoted (between 128 and 256 pages of cache) should be optimal
for a 4 Kb page size and 60 users, with a reasonable amount of RAM. Begin
with the lower number of pages (128), particularly if you have many queries
that use sorting (ORDER BY or GROUP BY).
./heLen
[Non-text portions of this message have been removed]