On Wed, Feb 24, 2016 at 12:01 PM, Hugo Eyng hugoeyng@... [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