> Thanks for the reply Thomas
>
> I forgot to mention that the 1000+ attachments we are expecting is over about 60 databases, where the maximum attachments to a single database is about 50. How will this affect the contention on the lock table?

Ah, ok, thought 1000+ attachments on a single database. Well, AFAIK, in
2.1, the lock table is per instance, while the lock table in 2.5 is per
database. Simply monitor the fb_lock_print output to possibly increase
the lock mem size and the hash locks value.

I would argue that serving the 60 databases with several Firebird
instances would make sense. Perhaps grouping the databases per instance
by QoS requirements ...


--
With regards,
Thomas Steinmaurer (^TS^)
Firebird Technology Evangelist

http://www.upscene.com/
http://www.firebirdsql.org/en/firebird-foundation/

> --- In firebird-support@yahoogroups.com, Thomas Steinmaurer<ts@...> wrote:
>>
>>> What is the current maximum number of connections firebird(2.1/2.5) can
>>> handle on a wondows 2008 r2 server. Is it still the 1024 limit set by the
>>> OS or has this changed?
>>
>> Just connecting with 2.5.2 SC 64-bit snapshot on Win 7 Prof. with 12GB
>> RAM and 75 page buffers without doing anything in context of these
>> connections:
>>
>> SQL> select count(*) from mon$attachments;
>>
>> COUNT
>> ============
>> 1201
>>
>> Perhaps higher possible. What you can see is that the number of threads
>> of the SC process stays at 1029. Doing some work then (with a SMP-test
>> utility I once wrote for a presentation; see below), you will get VERY
>> high (*g*) contention on the lock table:
>>
>> Hash slots: 1009, Hash lengths (min/avg/max): 57/ 83/ 102
>>
>> with the default hash slot value of 1009. Quit that test.
>>
>> The SMP-testing utility basically allows to simulate a configurable
>> number of client attachments via one thread per client attachment. It does:
>>
>> - Insert<n> records per attachment into a GTT via one simple stored
>> procedure call
>> - Each attachment will fetch the inserted records to the client
>>
>> Another workload with 1201 client attachments (2 SMP-test utility
>> instances running), processing (inserting into GTT and fetching) 5000
>> records each. This time with a higher hash slots value.
>>
>> - 5000 records per attachment into a global temporary table via one
>> simple stored procedure
>> - Each attachment will fetch the inserted records to the client
>>
>> My AMD hexa-core workstation was busy, but the test was finished in ~50
>> seconds. Took a lock print during the fetching phase.
>>
>> Hash slots: 10133, Hash lengths (min/avg/max): 0/ 4/ 15
>>
>>
>>> The question arises because we would like to consolidate two servers, and
>>> one of them already has about 800-900 attachements(A program written en
>>> delphi using a connected model). The other server has about 300
>>> attachements. serving websites and webservices(using connection pooling)
>>
>> The question is if you really need that number of physical connections
>> from your Delphi application and what you are doing in context of your
>> connections. If one instance doesn't handle the load, you still can run
>> a second on the same server, if you have enough resources available. But
>> these days, with low hardware prices, virtualization etc. ...
>>
>>
>> --
>> With regards,
>> Thomas Steinmaurer (^TS^)
>> Firebird Technology Evangelist
>>
>> http://www.upscene.com/
>> http://www.firebirdsql.org/en/firebird-foundation/
>>
>
>
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>