[SERVER-40298] Track transaction size on 4.0 Created: 22/Mar/19  Updated: 29/Oct/23  Resolved: 29/Mar/19

Status: Closed
Project: Core Server
Component/s: Diagnostics, Replication
Affects Version/s: None
Fix Version/s: 4.0.9

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Tess Avitabile (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Documented
is documented by DOCS-13195 Investigate changes in SERVER-40372: ... Closed
Related
related to SERVER-53609 lastCommittedTransaction section caus... Closed
related to SERVER-40372 Track transaction size on 4.2+ Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0
Sprint: Repl 2019-04-08
Participants:

 Description   

Adding metrics around the size of transactions could help us determine what use cases to optimize for. Metrics for the last run transaction:

  1. Number of operations in the transaction
  2. Total size of transaction statements in oplog
  3. Write Concern

There will be a new serverStatus section transactions.lastCommittedTransaction:

{
    "operationCount" : NumberLong(1),
    "oplogOperationBytes" : NumberLong(151),
    "writeConcern": {
        "w" : 1,
        "wtimeout" : 0
    }
}



 Comments   
Comment by Githook User [ 29/Mar/19 ]

Author:

{'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}

Message: SERVER-40298 Track transaction size
Branch: v4.0
https://github.com/mongodb/mongo/commit/7ea6e5dc1b7ab547dc45211d59eae19ecbda068e

Comment by Tess Avitabile (Inactive) [ 26/Mar/19 ]

Since we want these metrics on 4.0 quickly, and there is code motion on 4.2 due to Larger Transactions, I will implement this on 4.0 and forward-port if desired.

Comment by Tess Avitabile (Inactive) [ 25/Mar/19 ]

Metrics for the last run transaction will allow us to determine typical transactions workloads, so that we can target performance work toward those workloads. We considered instead outputting histograms of #ops and size of oplog entries, but we wanted to capture the relationships between these two metrics. We felt that capturing the last run transaction would allow us to decide what axes to look at after we have the data.

Since this information may only be useful for the Replication and Product teams, we could consider only providing it if requested and not documenting its existence (though we would need to change our data collection to request it).

Comment by Bruce Lucas (Inactive) [ 25/Mar/19 ]

Metrics for the last run transaction:

Generally speaking, cumulative metrics are preferred because they allow computing and charting averages over arbitrary sample intervals without sampling artifacts. For write concern we could record cumulative number of transactions for each write concern. Is there a specific use case that requires instead metrics for the last run transaction?

Generated at Thu Feb 08 04:54:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.