Subject | RE: [firebird-support] FB Crashing (again) |
---|---|
Author | Helen Borrie |
Post date | 2004-11-03T23:07:51Z |
At 05:23 PM 3/11/2004 -0500, you wrote:
executed by way of a single Autocommit transaction and the transaction
state bitmap (TSB) is getting so large that it is blowing available RAM.
Except for bad UDFs, that is the *most* common cause of server crashes when
the application is written in Delphi.
From googling MSDN and other sources, the magic number (4294967294, one
byte larger than the maximum amount of RAM that Windows can address) my
best current theory is that the TSB just gets so large that the next
resource request for the TSB causes Windows to kill the service.
That an inflated TSB can cause crashes is a given. At the moment, I'm
trying to determine if delivering the overflow number sent by the OS just
before Windows assassinates the service is what the server is expected to
do. I posted your previous message to firebird-devel, since it would be
handy to get some overflow scenarios.
./hb
>:: I suppose "2-3 of these a day" doesn't mean that usersOne possibility is that your "couple thousand things a day" are all being
>:: access fb db only 2 or 3 times a day.
>
>No, its not heavily used yet, but the DB is being used and processing at
>least a couple thousand things a day (selects, inserts, updates).
>
>:: Did you follow in which situations does it occurs? Could it
>:: be a concurrency problem? Some action that affect
>:: statistics? Does it occur in any situation?. How to obtain
>:: Firebird Team's opinion about this?.
>
>I have no idea... I don't even know when it crashes sometimes, I was just
>manually recovering it from another crash when I saw these in the log.
executed by way of a single Autocommit transaction and the transaction
state bitmap (TSB) is getting so large that it is blowing available RAM.
Except for bad UDFs, that is the *most* common cause of server crashes when
the application is written in Delphi.
From googling MSDN and other sources, the magic number (4294967294, one
byte larger than the maximum amount of RAM that Windows can address) my
best current theory is that the TSB just gets so large that the next
resource request for the TSB causes Windows to kill the service.
That an inflated TSB can cause crashes is a given. At the moment, I'm
trying to determine if delivering the overflow number sent by the OS just
before Windows assassinates the service is what the server is expected to
do. I posted your previous message to firebird-devel, since it would be
handy to get some overflow scenarios.
./hb