[SERVER-49794] Cap the size of transactions from flushing the size storer Created: 22/Jul/20  Updated: 30/Sep/20  Resolved: 30/Sep/20

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Eric Milkie Assignee: Eric Milkie
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to WT-6503 Cache stuck: eviction couldn't able t... Closed
Sprint: Execution Team 2020-08-10, Execution Team 2020-09-07, Execution Team 2020-09-21, Execution Team 2020-10-05
Participants:

 Description   

WiredTigerSizeStorer::flush() can end up creating a very large single transaction; this can be problematic for storage engines to handle.



 Comments   
Comment by Eric Milkie [ 30/Sep/20 ]

This doesn't seem to be necessary at this time; alternative modifications were made to the code to avoid stuck eviction.

Comment by Eric Milkie [ 11/Aug/20 ]

It's unclear if this is actually a problem that needs to be solved – waiting for more investigation the related ticket.

Comment by Eric Milkie [ 30/Jul/20 ]

Note that one possible way to have this happen would be to create a collection, insert one or more documents, and then drop that collection. If you did that 71,000 times, even if the collection name stayed the same, you could end up in the situation with 71,000 entries to be flushed in the size storer.

Comment by Eric Milkie [ 30/Jul/20 ]

The failure that triggered this investigation suggests that flush() generated a transaction with 71,000 inserts. For this to be possible, the size storer table in memory would need to have contained 71,000 entries representing 71,000 different collections. I am looking to see if that condition could have been met by that test run.

Generated at Thu Feb 08 05:20:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.