Issue Details (XML | Word | Printable)

Key: CORE-3656
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Thomas Steinmaurer
Votes: 1
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Support for sweep information in Trace API

Created: 07/Nov/11 09:28 PM   Updated: 23/Apr/13 01:24 PM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 2.5.2, 3.0 Alpha 1

Time Tracking:
Not Specified

Issue Links:
Relate
 

Planning Status: Unspecified


 Description  « Hide
Currently, the Trace API doesn't have any support for generating trace events when a sweep happens (starts/finishes). In the trace output, there should be a way to distinguish between a sweep, which has been triggered automatically (due to the sweep interval) and a sweep, which was invoked by the user manually.

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 28/Jun/12 07:15 AM
Improvement is committed into v2.5.2, v3 will follow soon

Vlad Khorsun added a comment - 28/Jun/12 07:34 AM
A documentation.

1. Trace configuration have new parameter (see fbtrace.conf)

# Sweep activity
#log_sweep false


2. Four new events related to sweep activity was introduced at the trace output:

a) SWEEP_START - when sweep process is started
Prints usual attachment info and transaction counters at the sweep start moment:

2012-06-26T14:17:28.1380 (3408:03828510) SWEEP_START
        EMPLOYEE.FDB (ATT_15285, SYSDBA:NONE, NONE, XNET:W2K3-X64)
        firebird\bin\gfix.exe:3516

Transactions counters:
        Oldest interesting 29418
        Oldest active 29419
        Oldest snapshot 29419
        Next transaction 29421


b) SWEEP_FINISH - when sweep finished successfully
Prints usual attachment info, transaction counters at the sweep finish moment and performance counters:

2012-06-26T14:17:28.1540 (3408:03828510) SWEEP_FINISH
        EMPLOYEE.FDB (ATT_15285, SYSDBA:NONE, NONE, XNET:W2K3-X64)
        firebird\bin\gfix.exe:3516

Transactions counters:
        Oldest interesting 29420
        Oldest active 29419
        Oldest snapshot 29419
        Next transaction 29421
     24 ms, 159 read(s), 10 write(s), 5365 fetch(es), 133 mark(s)


c) SWEEP_FAILED - when sweep process was failed (due to shutdown or on-disk error, etc)
Prints usual attachment info and performance counters. Transaction counters are not printed.

Note: failure reason is not printed, use log_errors parameter to obtain this info.


d) SWEEP_PROGRESS - put after processing of every non-empty relation
Prints usual attachment info and performance counters. Performance stats is reset after beign printed to
allow see separate stats for every relation (i.e. stats in this event is not accumulated during whole sweep
process) :

2012-06-26T14:17:28.1540 (3408:03828510) SWEEP_PROGRESS
        EMPLOYEE.FDB (ATT_15285, SYSDBA:NONE, NONE, XNET:W2K3-X64)
        firebird\bin\gfix.exe:3516
      0 ms, 2 read(s), 49 fetch(es)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
DEPARTMENT 21

2012-06-26T14:17:28.1540 (3408:03828510) SWEEP_PROGRESS
        EMPLOYEE.FDB (ATT_15285, SYSDBA:NONE, NONE, XNET:W2K3-X64)
        firebird\bin\gfix.exe:3516
      3 ms, 7 read(s), 1 write(s), 484 fetch(es), 129 mark(s)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$FORMATS 1
EMPLOYEE 42 42

Note: some metadata related activity could be present at stats.

Common notes:
- all sweep events are put before ATTACH_DATABASE event.
- auto-triggered sweep could be distinguished from manual-started sweep by user name at attachment info.
  For auto-triggered sweep it will be SWEEPER.

Thomas Steinmaurer added a comment - 28/Jun/12 07:55 AM
Very, very nice! Thanks for implementing this feature request!