Subject | Re: [firebird-support] Sweeping |
---|---|
Author | Helen Borrie |
Post date | 2006-04-24T00:33:47Z |
At 09:19 AM 24/04/2006, you wrote:
68,000 transactions at the server over this period and one or more
people were running COMMIT RETAINING transactions.
garbage is building up. It appears to have resolved itself
eventually after all the users went home. Unless you have users who
just switch off the computer without properly exiting your apps, I'd
be a bit suspicious that you have applications that are not leaving
transactions in a tidy state when they close. The server will
eventually decide that the transactions are dead and just roll them
back. Afterwards, regular GC or a sweep will deal with them and free
up channels to move the OAT and OIT forward.
visible until that transaction finishes. That gap of 700 "leftovers"
would probably include some transactions that either completed or
timed out during the sweep.
utility to look at all of the executing threads of the main fbserver
process. However, the server doesn't make any notifications about
any transactions. Transactions just "run their course", for better
or for worse. That is, after all, the idea of transaction isolation
- start a task, do some stuff, then either commit the work or roll it
back, with minimum impact on what anyone else is doing.
./heLen
>Hi All,It could be accounted for by "normal" activity if you were throwing
>
>Last week i asked about sweeping and the oit and oat. Curiously late
>friday i was monitoring this GAP value between OIT and OAT which had
>been steady and stable with a difference of 1 for most of the day.
>Then this GAP started to increase, going to >5000 then up to
>18000..I looked at what our systems were doing at this time and
>everything was normal activity just like during the day while the
>GAP had stayed steady at 1. I continued to monitor and this GAP
>value continued to climg to 35000 then to 52000 and ultimately to
>over 68000. The firebird server cpu showed normal activity and usage
>during this difference and there was no impact on our system all be
>it Friday after 5pm. Eventually the GAP fell back down to around 700
>not longer after. Does that sound normal for a Firebird 1.5 database
>server running on Windows 2000 server machine?
68,000 transactions at the server over this period and one or more
people were running COMMIT RETAINING transactions.
>I assume that although the GAP value was extremely high, it doesntCorrect. But what is does mean is that, during that period, a lot of
>mean there is a lot of unresolved transactions? it just means that
>there is a transaction way back down the line that has not been
>fully dealt with?
garbage is building up. It appears to have resolved itself
eventually after all the users went home. Unless you have users who
just switch off the computer without properly exiting your apps, I'd
be a bit suspicious that you have applications that are not leaving
transactions in a tidy state when they close. The server will
eventually decide that the transactions are dead and just roll them
back. Afterwards, regular GC or a sweep will deal with them and free
up channels to move the OAT and OIT forward.
>Also is sweeping a transaction and does that contribute to this GAPYes. Sweep runs in its own transaction so its effects won't be
>value while the sweep does its job, then once finished it goes away
>reducing the GAP value?
visible until that transaction finishes. That gap of 700 "leftovers"
would probably include some transactions that either completed or
timed out during the sweep.
>Is there anyway to know when a Sweep is running, can you set up someWith SS on Linux you could make an educated guess, using the ps
>notification when it occurs?
utility to look at all of the executing threads of the main fbserver
process. However, the server doesn't make any notifications about
any transactions. Transactions just "run their course", for better
or for worse. That is, after all, the idea of transaction isolation
- start a task, do some stuff, then either commit the work or roll it
back, with minimum impact on what anyone else is doing.
./heLen