Subject | Re: [firebird-support] Re: Firebird 2.1.3 Classic on Win2009 |
---|---|
Author | Ann W. Harrison |
Post date | 2010-11-10T16:16:12Z |
On 11/9/2010 7:45 PM, s3057043 wrote:
is coordinating access to database pages. Each database
page held in any cache is a Lock object; each copy in
the cache is a lock request. Reducing the number of
pages held in various caches reduces the number of locks
and lock requests, but it also (potentially) increases
the number of I/O requests. Locks are cheap compared with
I/O. First, increase the lock hash size (and possibly
the lock table size), then look at the cache size.
Firebird Classic was designed when machines had memory
measured in kilobytes - the first 1M machine we got was
really exciting. We couldn't get a gig of disk, and the
thought of a gig of memory ... wow what would you do with
that? The first rounds of performance testing used a
10 page cache - with 1024 byte pages. Over time, as
resources grow, the recommendations for memory use change.
I wouldn't reduce the cache size unless you're running
so many clients that you run out of memory.
Good luck,
Ann
>The major use of the lock table in Firebird Classic
> I noticed in a similar thread a few years back
> ( http://tech.groups.yahoo.com/group/firebird-support/message/82687 ) where you mention to reduce the size of the individual caches. Is this also something I need to look at doing?
>
is coordinating access to database pages. Each database
page held in any cache is a Lock object; each copy in
the cache is a lock request. Reducing the number of
pages held in various caches reduces the number of locks
and lock requests, but it also (potentially) increases
the number of I/O requests. Locks are cheap compared with
I/O. First, increase the lock hash size (and possibly
the lock table size), then look at the cache size.
Firebird Classic was designed when machines had memory
measured in kilobytes - the first 1M machine we got was
really exciting. We couldn't get a gig of disk, and the
thought of a gig of memory ... wow what would you do with
that? The first rounds of performance testing used a
10 page cache - with 1024 byte pages. Over time, as
resources grow, the recommendations for memory use change.
I wouldn't reduce the cache size unless you're running
so many clients that you run out of memory.
Good luck,
Ann