> 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 [email protected], 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 > > >
