[SERVER-35157] Add transactions latency tracking to OperationLatencyHistogram Created: 22/May/18 Updated: 29/Oct/23 Resolved: 05/Jul/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Nathan Louie |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | global-txn-metrics | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Repl 2018-07-02, Repl 2018-07-16 | ||||||||
| Participants: | |||||||||
| Description |
|
To support the tracking of transaction latency information in serverStatus, we want to add a transactions section to the OperationLatencyHistogram class. We can add a HistogramData _txns member variable, analogous to the existing _reads, _writes and _commands variables. We will also need to add a new Command::ReadWriteType type that represents a multi-document transaction. |
| Comments |
| Comment by Githook User [ 16/Aug/18 ] | ||||||||
|
Author: {'username': 'nxlouie', 'email': 'nathan.louie@10gen.com', 'name': 'Nathan Louie'}Message: (cherry picked from commit 96c5d840db4f4279cd9fc8ffe4bdfdc60fcd3984) | ||||||||
| Comment by Githook User [ 05/Jul/18 ] | ||||||||
|
Author: {'username': 'nxlouie', 'name': 'Nathan Louie', 'email': 'nathan.louie@10gen.com'}Message: | ||||||||
| Comment by William Schultz (Inactive) [ 30/May/18 ] | ||||||||
|
To Kyle's point, it is simply the first command of a transaction that marks its "start". The latency should be measured from that time until the commit or abort event. To Bruce's last comment, yes I think that is roughly correct, but that will be fleshed out separately, in the tickets for tracking abort causes and their counts. | ||||||||
| Comment by Bruce Lucas (Inactive) [ 24/May/18 ] | ||||||||
|
There's no startTransaction command as such, but indeed commitTransaction and abortTransaction will show up in the command section. I think that transactions that time out should be counted in transactions.totalAborted, and there should be a transactions.abortCause.timedOut counter, alongisde transactions.abortCause.aborted (for explicitly aborted transactions). william.schultz, do you agree? (Also I think this comment goes with a different ticket). | ||||||||
| Comment by Kyle Suarez [ 23/May/18 ] | ||||||||
|
Cool, thanks for confirming. Also, startTransaction, commitTransaction and abortTransaction are all themselves commands, so I presume they will show up in the "command" section as well. The transaction reaper will have to be updated to make sure it records the total time of the transaction when killing it. This reaping probably should not count as an explicit abortTransaction, though. | ||||||||
| Comment by Bruce Lucas (Inactive) [ 23/May/18 ] | ||||||||
|
Yes, that's the intent. | ||||||||
| Comment by Kyle Suarez [ 23/May/18 ] | ||||||||
|
To clarify, this section tracks the latency of an entire transaction, from startTransaction to commit or abort? For example, if a user does
then the global operation latency histogram will have entries for two reads, one write and two transactions? |