Subject | Re: [firebird-support] questions on firebird, mainly obscure |
---|---|
Author | Ann W. Harrison |
Post date | 2007-11-09T23:12:10Z |
Carrell Alex wrote:
reporting 1500.
you're also loading up the lock table pretty heavily. There's one
lock per page in cache, plus a request tying the lock to the owner.
If a single page is in two caches, there's one lock plus one request
per client sharing the page.
Although the problem with large caches has been solved in SuperServer,
large caches are still not cost-effective in classic. The problem is
that client A reads 5000 pages to compute an average, for example,
and since he's still got space in his cache, the pages just sit there.
Client B wants to change something on one of those pages and has to
wake Client A to get him to release his lock. If A had just dumped
the page, the interaction wouldn't have been necessary. Worse is
when A does a whole bunch of changes without committing them (which
flushes them out of cache), then B wants a page. A has to wake up
write the page and release his lock. Then B has to read the page
of disk. So B has to wait for both a write and a read.
Yes there are all sorts of papers on how to manage caches so an
aggregate operation uses only a few pages. We just don't do that.
Yet.
Best,
Ann
>Are you sure? (You probably are.) I wonder why the stats are
> I have looked at that.
> Running with 75 at moment, probably move to minimum/65 and up page size to
> 8192. Server works well with your suggestion.
>
reporting 1500.
> Shadow count 0If for some reason you're actually using 15000 buffers per client,
> Page buffers 15000
> Next header page 0
you're also loading up the lock table pretty heavily. There's one
lock per page in cache, plus a request tying the lock to the owner.
If a single page is in two caches, there's one lock plus one request
per client sharing the page.
Although the problem with large caches has been solved in SuperServer,
large caches are still not cost-effective in classic. The problem is
that client A reads 5000 pages to compute an average, for example,
and since he's still got space in his cache, the pages just sit there.
Client B wants to change something on one of those pages and has to
wake Client A to get him to release his lock. If A had just dumped
the page, the interaction wouldn't have been necessary. Worse is
when A does a whole bunch of changes without committing them (which
flushes them out of cache), then B wants a page. A has to wake up
write the page and release his lock. Then B has to read the page
of disk. So B has to wait for both a write and a read.
Yes there are all sorts of papers on how to manage caches so an
aggregate operation uses only a few pages. We just don't do that.
Yet.
Best,
Ann