| Subject | Re: [ib-support] Page Size - newbie Question |
|---|---|
| Author | Helen Borrie |
| Post date | 2002-11-17T11:51:38Z |
At 12:34 PM 17-11-02 +0200, you wrote:
for rows for a table, part of an index, a blob, etc., different page types
for different categories of data).
A page is also the unit in which the server's memory is measured.
disk cost a month's salary. Try 4K or 8K; but if you have some row
structures that are larger than 8K, or want to store a lot of large blobs,
a 16K size is available for Firebird.
can be a useful guideline. Think in terms of "how many of these could fit
onto a page?" (allowing for about 80% fill). The more you can fit into one
page, the fewer the pages that need to be searched. FB and IB don't store
the pages for a particular object in contiguous areas of disk but e.g. for
tables, a single page accommodates either n complete rows, or else a part
of a row in cases where the page size is too small to accommodate a whole
row. (Don't include the size of blobs in the row, since they are not
stored in the row pages).
a higher or lower number of pages (default is 256) - this is a bit of a
science in itself.
deployment environment. In either case, if server is doing nothing but
serving your databases, the platform doesn't influence your choice of page
size. If you have a Windows server doubling up as something else, you'll
get competition no matter what the page size; but if the page size is too
small and there is competition for i/o resources, the extra i/o won't be
good for performance. If your server cache is too large and there's
competition from other Windows apps for memory, the cache will pag out a
lot and defeat the usefulness of having a cache. Test, test and test,
monitor everything.
it creates one for each connection, whereas SS has a pooled cache which
will grow if required.
None of this is the whole story. Every database is different. Every
application environment is different.
heLen
>What is a Page ?It is a block of disk space into which Firebird stores data (might be data
for rows for a table, part of an index, a blob, etc., different page types
for different categories of data).
A page is also the unit in which the server's memory is measured.
>How do I decide what page size is best.1K and 2K are no good for anything except to remind us that, once, a 500 Mb
>1K or 4k.
disk cost a month's salary. Try 4K or 8K; but if you have some row
structures that are larger than 8K, or want to store a lot of large blobs,
a 16K size is available for Firebird.
>Is there any steps a procedure that could help me,Not steps, per se; but the size of your largest frequently accessed row
>to optimize performance regarding this.
can be a useful guideline. Think in terms of "how many of these could fit
onto a page?" (allowing for about 80% fill). The more you can fit into one
page, the fewer the pages that need to be searched. FB and IB don't store
the pages for a particular object in contiguous areas of disk but e.g. for
tables, a single page accommodates either n complete rows, or else a part
of a row in cases where the page size is too small to accommodate a whole
row. (Don't include the size of blobs in the row, since they are not
stored in the row pages).
>If I have litle RAM ,, what do I use.A server with more memory. :-) Actually, you can adjust the cache size to
a higher or lower number of pages (default is 256) - this is a bit of a
science in itself.
>If I run Linux ...Lots of variables there and no rules except the pragmatics of your actual
>If I run Windows ...
deployment environment. In either case, if server is doing nothing but
serving your databases, the platform doesn't influence your choice of page
size. If you have a Windows server doubling up as something else, you'll
get competition no matter what the page size; but if the page size is too
small and there is competition for i/o resources, the extra i/o won't be
good for performance. If your server cache is too large and there's
competition from other Windows apps for memory, the cache will pag out a
lot and defeat the usefulness of having a cache. Test, test and test,
monitor everything.
>Classic Server or Super Server...No difference on disk; but Classic uses the cache less efficiently, since
it creates one for each connection, whereas SS has a pooled cache which
will grow if required.
None of this is the whole story. Every database is different. Every
application environment is different.
heLen