Subject | Re: [Firebird-Architect] Future Performance Question |
---|---|
Author | Dmitry Yemanov |
Post date | 2006-10-04T06:24:13Z |
Greg Kay wrote:
v2.1.
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).
heavy load much better.
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...
classic.
Dmitry
>There were no such plans, but I think it's doable (up to 32K slots) for
> 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?
v2.1.
> The other issue is about the maximum number of connections allowed. II often hear about such a limit, but to the best of my knowledge it's
> believe superserver has a 1,024 connection limit.
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 testingCorrect.
> 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.
> 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 may250GB database is not a real problem, provided that you upgrade to FB2
> 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
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