Subject | Re: [firebird-support] High Mutex Wait Figures |
---|---|
Author | Ann W. Harrison |
Post date | 2006-12-01T17:12:03Z |
Greg Kay wrote:
to update the lock table. In classic, though we talk about the lock
manager as if it were a separate process, the code is actually in
each process. In the early dark ages there were implementations that
had a separate lock manager process, but they're long gone. When a
process wants to request or release a lock, it puts itself on a queue
for the mutex that guards the table. When it gets that mutex, it makes
its changes - sending signals as necessary - and releases the mutex.
The goal is for the changes to be really really fast.
From the lock prints you sent, it looks as if each change is taking
longer than it should.
How many buffers are you using per connection?
Regards,
Ann
> Does anyone have any ideas on what might be causing high mutex waitThe mutex wait is amount of time processes spend waiting their turn
> figures?
to update the lock table. In classic, though we talk about the lock
manager as if it were a separate process, the code is actually in
each process. In the early dark ages there were implementations that
had a separate lock manager process, but they're long gone. When a
process wants to request or release a lock, it puts itself on a queue
for the mutex that guards the table. When it gets that mutex, it makes
its changes - sending signals as necessary - and releases the mutex.
The goal is for the changes to be really really fast.
From the lock prints you sent, it looks as if each change is taking
longer than it should.
How many buffers are you using per connection?
Regards,
Ann