Thanks for your reply Dmitry.

What would be required to get the hash slots increased to 32K in FB 2.1?

Also, in FB 3 there will be no Classic, so will there be a 1024 limit on
the number of connections? If this is the case, then we wouldn't be able
to use FB 3 until we had finished our conversion to 3 tier.

Greg

--- In Firebird-Architect@yahoogroups.com, Dmitry Yemanov <dimitr@...>
wrote:

>
> Greg Kay wrote:
> >
> > In our current Firebird system, we have the hash slots value in the
> > lock manager set to the maximum. Even with this, fb_lock_print
> > indicates that we are close to the recommended figures of hash
> > lengths. An example is below. Are there any plans to increase the
> > hash slots limit? Does the Vulcan or Firebird 3 or 64 bit Firebird 2
> > versions change any of this?
>
> There were no such plans, but I think it's doable (up to 32K slots)

for

> v2.1.
>
> > The other issue is about the maximum number of connections allowed.

I

> > believe superserver has a 1,024 connection limit.
>
> I often hear about such a limit, but to the best of my knowledge it's
> not hardcoded. However, the current superserver cannot handle such a
> concurrent load efficiently, so I think this is a kind of practical
> limit (or perhaps there was an explicit limit in some IB versions).
>
> > From my testing
> > Classic doesn't seem to have this limit. I was able to get 3,000
> > connections without much problem although I didn't do a lot of work
> > with them so don't know how badly the lock manager would cope with
> > these numbers. So it looks like connections are only limited by your
> > hardware in classic.
>
> Correct.
>
> > Does anybody know if this will change with Firebird 2 or 3?
>
> If you talk about superserver, then yes - FB3 is expected to handle
> heavy load much better.
>
> > Lastly, does anybody know of any other limits or problems we may
> > encounter if we try to increase the amount of processing we are

doing

> > by a factor of 5 or 10? I.e., 250 gig database, 1500 connections,

10

> > million transactions a day probably
>
> 250GB database is not a real problem, provided that you upgrade to FB2
> and tune all your queries properly (and don't allow ad-hoc queries).

10M

> transactions a day is not a showstopper either, but you'll be required
> to perform a full backup/restore cycle at least once per year, in

order

> to reset transaction counters (they're 32-bit and not wrappable). 1500
> connections is a bit worse...
>
> > on something like a linux 8 cpu dual core cpu with 128 gig ram
>
> ... but such a platform should be able to deal with that, if you run
> classic.
>
>
> Dmitry
>