[DOCS-11599] Docs for SERVER-33295: Kill long-running snapshot transactions Created: 13/Apr/18  Updated: 29/Oct/23  Resolved: 04/Jun/18

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 3.7.4

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

Issue Links:
Documented
documents SERVER-33295 Kill long-running snapshot transactions Closed
Related
is related to DOCS-11505 Document Transactions Closed
is related to DOCS-11619 Docs for SERVER-33412: Error on write... Closed
Participants:
Days since reply: 5 years, 36 weeks, 2 days ago
Epic Link: DOCS: 4.0 Server

 Description   

Documentation Request Summary:

Added a new server parameter transactionLifetimeLimitSeconds. Settable on startup and via setParameter, retrievable via getParameter. Defaults to 60 seconds. Minimum acceptable value is 1 second. Only useful on storage engines that support transactions.

Dictates the lifetime given to each transaction, after which a periodic (runs every transactionLifetimeLimitSeconds/2 seconds, or at most once per second and at least once per minute) background thread will find and abort the transaction.

Each transaction maintains a snapshot of the storage engine data at a point in time, requiring the storage engine to maintain that history all the way back to that point in time, which has the potential to fill up its cache and immobilize the system. Users may also forget to commit transactions, in which case they should be cleaned up eventually. Transactions therefore must expire to preempt storage cache pressure immobilizing the system.

Scope of changes:

  • Parameter page
  • added a Production Consideration section
    • runtime limit section
    • actively abort when abandoning transactions
  • Release notes

Impact to other docs outside of this product:

None

MVP:

Resources:

Engineering Ticket Description:

From the design,

"Motivation:
The "oldest" open transaction in WiredTiger will pin write history in cache until it finishes. Here, "oldest" means the read timestamp is the earliest of any open transaction on the system. Any write history with a timestamp equal to or newer than this read timestamp must stay pinned in cache, in order to serve the open transaction. We need a way to prevent these transactions from staying open too long, in order to prevent cache pressure from becoming too extreme."

Adding a transactionLifetimeLimitSeconds server parameter, which can be set at startup and via setParameter. Transaction will now expire, per the server parameter, and be asynchronously periodically cleaned up.



 Comments   
Comment by Githook User [ 04/Jun/18 ]

Author:

{'username': 'kay-kim', 'name': 'kay', 'email': 'kay.kim@10gen.com'}

Message: DOCS-11599,DOCS-11696, DOCS-11750, DOCS-11658, DOCS-11619: txn retry, timelimit, speculative, write concern, informational ops
Branch: master
https://github.com/mongodb/docs/commit/5ae9b807789577b7ca926f689baa013061abc34c

Comment by Kay Kim (Inactive) [ 17/Apr/18 ]

no worries.

Comment by Dianna Hohensee (Inactive) [ 17/Apr/18 ]

It was decided that this shall be documented. Sorry for the confusion!

Comment by Kay Kim (Inactive) [ 13/Apr/18 ]

Thanks.

Comment by Dianna Hohensee (Inactive) [ 13/Apr/18 ]

Uncertain whether this should be documented. Will update.

Generated at Thu Feb 08 08:03:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.