On 13 September 2011 15:43, Ann Harrison <aharrison@...> wrote:

> **
>
>
> On Tue, Sep 13, 2011 at 4:40 AM, Nick Upson <nu@...> 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]