Subject | Re: [firebird-support] What is wrong with transactions here? |
---|---|
Author | marcus |
Post date | 2014-11-04T20:05:48Z |
On 04.11.2014 16:21, simion_coroama@... [firebird-support] wrote:
connect to the database and how the applications are handling their
connects, statements and commits - you will see a gap between the oldes
active and the next transaction.
For example, you'll need firebirds isql and a shell (cmd, bash, whatever).
Open a shell, create a database and a simple table within, one integer
will be enough. Now insert 1 integer into that table and don't commit!
Open a second shell, gstat -h with the database from above.
Open a third shell, isql with the database do a couple of inserts and
commit after each single one. A last insert, don't commit!
Change to shell number two, gstat -h again: See the difference between
oldest active and next transaction?
Now switch to the first shell and commit the insert, close isql.
What is gstat showing?
Commit the last insert from the third shell close isql.
Now you should have a difference of one between the oldest active and
the next transaction.
The bigger the gap (the transaction chain) gets, the slower each
database action gets. Sweeping tries to detect and remove commited
transactions in the chain to keep it short. The problem is: it requires
database performance. So if the database is under "heavy fire", it may
be better to disable housekeeping and trigger it manually. Another
option you should think about: How the connections and that are handled
from the application side? Do you have a chance to optimize that handling?
See also:
https://www.ibphoenix.com/resources/documents/design/doc_21
https://www.ibphoenix.com/resources/documents/general/doc_67
http://conferences.embarcadero.com/article/32280/
>That's housekeeping for transactions. Depending on how applications are
>
> Hi!
>
> I have some lines in firebird.log like this:
> ===================
> cxv.servers.net Tue Nov 4 11:37:38 2014
> Sweep is started by SWEEPER
> Database "SkyNetInt"
> OIT 1221095, OAT 1231335, OST 1231313, Next 139981575359934
>
>
> cxv.servers.net Tue Nov 4 11:37:46 2014
> Sweep is finished
> Database "SkyNetInt"
> OIT 1248701, OAT 1248707, OST 1248707, Next 1248709
>
> ===================
connect to the database and how the applications are handling their
connects, statements and commits - you will see a gap between the oldes
active and the next transaction.
For example, you'll need firebirds isql and a shell (cmd, bash, whatever).
Open a shell, create a database and a simple table within, one integer
will be enough. Now insert 1 integer into that table and don't commit!
Open a second shell, gstat -h with the database from above.
Open a third shell, isql with the database do a couple of inserts and
commit after each single one. A last insert, don't commit!
Change to shell number two, gstat -h again: See the difference between
oldest active and next transaction?
Now switch to the first shell and commit the insert, close isql.
What is gstat showing?
Commit the last insert from the third shell close isql.
Now you should have a difference of one between the oldest active and
the next transaction.
The bigger the gap (the transaction chain) gets, the slower each
database action gets. Sweeping tries to detect and remove commited
transactions in the chain to keep it short. The problem is: it requires
database performance. So if the database is under "heavy fire", it may
be better to disable housekeeping and trigger it manually. Another
option you should think about: How the connections and that are handled
from the application side? Do you have a chance to optimize that handling?
See also:
https://www.ibphoenix.com/resources/documents/design/doc_21
https://www.ibphoenix.com/resources/documents/general/doc_67
http://conferences.embarcadero.com/article/32280/
>as far as i know : same as winsock 10054 : unable to connect to client
> sometime this happen in few hours.
>
> How can I find where is the problem?
>
>
> I don't know if it's important, a lot of lines is:
>
> =================
>
> cxv.servers.net Tue Nov 4 11:32:50 2014
> INET/inet_error: read errno = 104
> =================
>[Non-text portions of this message have been removed]
>
> Thanks!
>
>
>