[SERVER-29150] Oplog/Snapshot/Memory Created: 11/May/17  Updated: 12/May/17  Resolved: 12/May/17

Status: Closed
Project: Core Server
Component/s: Internal Code, Replication, Write Ops
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: deyukong Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

If allow readMajority, snapshotManager will be opened on mongo-wt or mongorocks.
We assume there are 2 secondaries after a primary.
One snapshot(exactly saying, one in snapshotmanager, one in repl module, about 8+8*2 = 24 bytes) will be held for each oplog entry in memory,
If both of the two secondaries are almost stale(but still catches with primary), snapshot will not be committed, neither memory nor disk can not be released, it can be quite dangerous.Am I right?

My question is:
1) If both secondaries are stale, but primary still alives and keeps writing. More snapshots will be generated, Does it lead to an oom finally ?
2) Plz figure out the misunderstandings above, thanks.



 Comments   
Comment by deyukong [ 12/May/17 ]

thanks for your reply.
I will forward this issue to the dev group.
I read too fast and ignored shouldSleepMore, which will control the max snapshot nums.

Comment by Eric Milkie [ 12/May/17 ]

Thanks for your report. Please note that SERVER project is for reporting bugs or feature suggestions for the MongoDB server. For MongoDB-developer related support discussion please post on the mongodb-dev group. A question like this involving more discussion would be best posted on the mongodb-dev group.

Comment by Eric Milkie [ 12/May/17 ]

In your scenario, as more writes happen, the WiredTiger cache will eventually fill up with update data. This data is then spilled to disk in a LAS (lookaside) file. While performance will suffer when this happens, it should not run out of memory.

Comment by Eric Milkie [ 12/May/17 ]

Named snapshots for the purposes of satisfying read-concern-majority are limited to 1000. There is an algorithm that controls this at https://github.com/mongodb/mongo/blob/3448ddb2ec7b3e210dfc97c0296dd7496f5c7813/src/mongo/db/repl/oplog.cpp#L1163

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