Subject | Re: [firebird-support] Firebird 2.1.3 Classic on Win2009 |
---|---|
Author | Ann W. Harrison |
Post date | 2010-11-09T23:34:45Z |
On 11/9/2010 6:23 PM, s3057043 wrote:
waiting to make changes to the lock table. 64.6% is huge. 10%
is excessive. One reason for long waits is that the transaction
that has mutex for the table takes a long time to find the objects
it wants to change. It finds them by hashing on their identifier
and walking down the hash chain until it finds the right object.
If there's only one object in the hash chain, that's quick. If
there are 22, that's a problem.
Increase your hash table size.
Good luck,
Ann
> Hello Group,...
>
> I am looking into a particular server that has been performing slowly at certain times of the week. The server is running Firebird 2.1 CS on Win 2008 R2 and on any given day is serving between 80 and 250 concurrent connections.
>
>
> The output of fb_lock_print is too large to post, but the header is here.
>
> LOCK_HEADER BLOCK
> Mutex wait: 64.6%The mutex wait relates to the amount of time transactions spend
> Hash slots: 1009, Hash lengths (min/avg/max): 2/ 10/ 22
waiting to make changes to the lock table. 64.6% is huge. 10%
is excessive. One reason for long waits is that the transaction
that has mutex for the table takes a long time to find the objects
it wants to change. It finds them by hashing on their identifier
and walking down the hash chain until it finds the right object.
If there's only one object in the hash chain, that's quick. If
there are 22, that's a problem.
Increase your hash table size.
Good luck,
Ann