« Return to Thread: Re: [firebird-support] gds_thread_enter contention
Re: [firebird-support] gds_thread_enter contention
by Bud Millwood
::
Rate this Message:
On Tuesday 06 May 2008, Dmitry Yemanov wrote:
<originally posted on the support forums>
> Bud Millwood wrote:
> > - Does the fbclient library acquire a process-wide lock when a thread
> > passes through it (even when connecting to fb-classic)? If so, doesn't
> > that counteract the gains we get by running multiple fb-classic
> > instances?
>
> Yes, fbclient is synchronized using some kind of global mutex. It is
> acquired when any thread enters the API call and released as soon as the
> network packet is ready to be sent to the remote server. So, the
> blocking time is very short (compared to the network transport overhead
> and the server side processing of the call) and I don't think it really
> limits your performance.
Hi Dmitry:
I grabbed a developer here this morning and went back over our logic and our
numbers, and we are both now reasonably sure that this lock *is* the source
of the high contention. And from what we can tell, this lock is causing
Firebird to fail to scale to its full potential.
We haven't yet looked at the source, but my guess is that it's locking a
container in order to find the thread's TCP socket - is that right? Is is it
doing more than that?
We may start digging around in the fbclient source to try to figure out a way
to make this lock-free. One idea, which could be difficult depending on the
FB API, would be to embed the socket descriptor in the connection handle
that's held by the application thread. If that were possible, and the
fbclient library is doing what I think it's doing, then that would result in
lock-free access to the database.
- Bud
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
<originally posted on the support forums>
> Bud Millwood wrote:
> > - Does the fbclient library acquire a process-wide lock when a thread
> > passes through it (even when connecting to fb-classic)? If so, doesn't
> > that counteract the gains we get by running multiple fb-classic
> > instances?
>
> Yes, fbclient is synchronized using some kind of global mutex. It is
> acquired when any thread enters the API call and released as soon as the
> network packet is ready to be sent to the remote server. So, the
> blocking time is very short (compared to the network transport overhead
> and the server side processing of the call) and I don't think it really
> limits your performance.
Hi Dmitry:
I grabbed a developer here this morning and went back over our logic and our
numbers, and we are both now reasonably sure that this lock *is* the source
of the high contention. And from what we can tell, this lock is causing
Firebird to fail to scale to its full potential.
We haven't yet looked at the source, but my guess is that it's locking a
container in order to find the thread's TCP socket - is that right? Is is it
doing more than that?
We may start digging around in the fbclient source to try to figure out a way
to make this lock-free. One idea, which could be difficult depending on the
FB API, would be to embed the socket descriptor in the connection handle
that's held by the application thread. If that were possible, and the
fbclient library is doing what I think it's doing, then that would result in
lock-free access to the database.
- Bud
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
« Return to Thread: Re: [firebird-support] gds_thread_enter contention
| Free embeddable forum powered by Nabble | Forum Help |
