| Firebird Documentation Index → Firebird 2.1 Release Notes → Global Improvements in Firebird 2.1 → Configuration and Tuning |
|
|
|
Feature requests CORE-958 and CORE-937
the maximum number of hash slots is raised from 2048 to 65,536. Because the actual setting should be a prime number, the exact supported maximum is 65,521 (the biggest prime number below 65,536). The minimum is 101.
the new default number of hash slots is 1009
the default lock table size has been increased to 1 Mb on all platforms
Page sizes of 1K and 2K are deprecated as inefficient.
The small page restriction applies to new databases only. Old ones can be attached to regardless of their page size.
Until v.2.1, Firebird had no special rules about allocating disk space for database file pages. Because of dependencies between pages that it maintains itself, to service its “careful write” strategy, it has just written to newly-allocated pages in indeterminate order.
For databases using ODS 11.1 and higher, Firebird servers from v.2.1 onward use a different algorithm for allocating disk space, to address two recognised problems associated with the existing approach:
Corruptions resulting from out-of-space conditions on disk
The indeterminate order of writes can give rise to a situation that, at a point where the page cache contains a large number of dirty pages and Firebird needs to request space for a new page in the process of writing them out, there is insufficient disk space to fulfil the request. Under such conditions it often happens that the administrator decides to shut down the database in order to make some more disk space available, causing the remaining dirty pages in the cache to be lost. This leads to serious corruptions.
File fragmentation
Allocating disk space in relatively small chunks can lead to significant fragmentation of the database file at file system level, impairing the performance of large scans, as during a backup, for example.
The solution is to introduce some rules and rationales to govern page writes according to the state of available disk space, as follows.-
Each newly allocated page writes to disk immediately before returning to the engine. If the page cannot be written then the allocation does not happen: the PIP bit remains uncleared and the appropriate I/O error is raised. Corruption cannot arise, since it is guaranteed that all dirty pages in cache have disk space allocated and can be written safely.
Because this change adds an extra write for each newly-allocated page, some performance penalty is to be expected. To mitigate the effect, writes of newly-allocated pages are performed in batches of up to 128 Kb and Firebird keeps track of the number of these “initialized” pages in the PIP header.
A page that has been allocated, released and re-allocated is already “space in hand”, meaning that no further verification is required in order to “initialize” it. Hence, a newly allocated page is subjected to this double-write only if it is a block that has never been allocated before.
To address the issue of file fragmentation, Firebird now uses the appropriate call to the API of the file system to preallocate disk space in relatively large chunks.
Preallocation also gives room to avoid corruptions in the event of an “out of disk space” condition. Chances are that the database will have enough space preallocated to continue operating until the administrator can make some disk space available.
Windows Only (for Now)
Currently, only Windows file systems publish such API calls, which means that, for now, this aspect of the solution is supported only in the Windows builds of Firebird. However, similar facilities have recently been added to the Linux API, allowing the prospect that a suitable API function call will appear in such popular file systems as ext3 in future.
For better control of disk space preallocation, the new parameter
DatabaseGrowthIncrement has been added to firebird.conf.
It represents the upper limit for the preallocation chunk size in bytes.
Please be sure to read the details regarding this configuration, under DatabaseGrowthIncrement in the chapter entitled “New Configuration Parameters and Changes”.
Feature requests CORE-1381 and CORE-1480
Firebird uses and maintains its own cache in memory for page buffers. The operating system, in turn, may re-cache Firebird's cache in its own filesystem cache. If Firebird is configured to use a cache that is large relative to the available RAM and Forced Writes is on, this cache duplication drains resources for little or no benefit.
Often, when the operating system tries to cache a big file, it moves the Firebird page cache to the swap, causing intensive, unnecessary paging. In practice, if the Firebird page cache size for Superserver is set to more than 80 per cent of the available RAM, resource problems will be extreme.
Filesystem caching is of some benefit on file writes, but only if Forced Writes is OFF, which is not recommended for most conditions.
Now, Superserver on both Windows and POSIX can be configured by a new configuration parameter, MaxFileSystemCache, to prevent or enable filesystem caching. It may provide the benefit of freeing more memory for other operations such as sorting and, where there are multiple databases, reduce the demands made on host resources.
For Classic, there is no escaping filesystem caching.
For details of the MaxFileSystemCache parameter, see MaxFileSystemCache.
|
| Firebird Documentation Index → Firebird 2.1 Release Notes → Global Improvements in Firebird 2.1 → Configuration and Tuning |