On Wed, Feb 24, 2016 at 12:01 PM, Hugo Eyng hugoe...@msn.com [firebird-support] <firebird-support@yahoogroups.com> wrote:
Referring to the buffers requested for gbak: > > > Why 120000? Why not? :) > There's a cost to managing a large buffer cache. Firebird will use the entire cache even if there's no particular reason to do so. A gbak backup needs a few dozen pages for system table stuff that's referenced frequently and for each table backed up another few pages that help locate data. The data pages are read once and then are of no more interest. So the default cache size is fine for a backup. Two hundred pages is probably enough to backup almost any database. If you use a huge cache, it will be filled with useless data pages. A gbak restore needs the same few dozen pages of system tables and some pages for internal table management. When it is restoring data, it fills a data page and goes on to the next one. A large cache will fill with pages that will not be referenced again until the indexes are built. To build indexes, Firebird reads records and sorts by keys. That might suggest that keeping millions of pages in cache would improve performance by eliminating disk reads. However, unless you've got a huge amount of memory, those data pages will reduce the amount of memory available for the sort. The sort algorithm produces chunks of sorted key/record id pairs which are subsequently merged. The more chunks that can be kept in memory, the faster the sort. If you've used all your machine's memory for the cache, the sort will be slow and may start paging. Good luck, Ann
