On 13 September 2011 15:43, Ann Harrison <[email protected]> wrote:
> ** > > > On Tue, Sep 13, 2011 at 4:40 AM, Nick Upson <[email protected]> wrote: > > > > > Sorry I wasn't clear, it is being suggested that lowering the priority of > > the fb_inet_server process associated with the backup (gbak) will allow > the > > other instances to run better. > > I recall that adjusting the server process priorities is a bad idea (TM) > > but > > I forget (and can't find) why > > OK. During a backup, gbak reads every data page, every pointer page, and > every page inventory page. That's a lot of pages. For each page it reads, > it holds a shared lock. Any other connection that wants to change data > needs an exclusive lock on the pages it changes, which is incompatible with > gbak's shared lock. If gbak can't get the cycles to release locks on > request, it will slow down everything. A better way to make gbak a good > world citizen would be to reduce the cache size on its connection so it > automatically throws out old data pages that it will not revisit. > > > Good luck, > > Ann > > > That sounds very useful but I didn't think there was a way to affect the gbak-using fb_inet_server without affecting all others as well (fb 2.1.4 on Centos) -- Nick Upson [Non-text portions of this message have been removed]
