[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: |
|
||||||||
| 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. |