| Subject | Re: AW: [firebird-support] Problem Firebird Classic Server |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-06-10T15:10:09Z |
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
>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