(Does this question belong on support or devel?)

I have a question about thread contention in gds_thread_enter. Here are the
details of our setup:

Firebird: 2.0.3
Firebird Arch: Classic
System Arch: amd64
System CPUs: 2 (dual-quad)
System Cores: 8
OS: Ubuntu 7.10
Access mode: one db connection per thread
Number of threads: Tested with 2, 3, 4 and 6 threads

We've reduced our application's locks down to what we believe are zero,
but 'strace -o output.txt -c -p <pid>' for any of these high-throughput
threads shows a large amount of calls to 'futex'. The time spent in
the 'futex' call is very large when there are a lot of threads:

- 6 threads (75% time spent in 'futex')
- 4 threads (60% time spent in 'futex')
- 3 threads (34% time spent in 'futex')
- 2 threads (6% time spent in 'futex')

Running valgrind and finding calls to 'pthread_mutex_lock' shows that there
are a lot of calls made from 'gds_thread_enter'.

These futex calls are in my server's process, so the only thing I can make of
all this is that there is a lot of contention in the firebird client library.

We're running about 600 transactions per second with 6 threads. 6 app threads
+ six fb-classic instances is 12 schedulable items, which is more than the
optimal 8. We seem to top out at about 4 threads, which I suppose would be
the max for this machine, except I don't expect to see it topped out sitting
in calls to 'futex'. I expect it to be doing something more useful. :)

So the questions are:

- 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?

(Note: the question is whether a lock which could be highly contended is
acquired - not whether the threads are fully serialized to the database,
which I understand they're not)

- Has anyone managed more than 600 TPS in any Firebird configuration?

- Is this just a performance limitation in Firebird?


- Bud