[SERVER-3509] madvise(DONT_NEED) portions of oplog all slaves have synced Created: 01/Aug/11  Updated: 19/Mar/13  Resolved: 08/Mar/13

Status: Closed
Project: Core Server
Component/s: Performance, Replication
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Mathias Stearn Assignee: Mathias Stearn
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-2126 test use of madvise to improve perfor... Closed
Participants:

 Description   

Since we won't need that data again until after wrap-around there is no point in keeping it in the page cache.

madvise(SEQUENTIAL) is probably a good idea for the whole oplog as well.



 Comments   
Comment by Mathias Stearn [ 01/Aug/11 ]

I was thinking that this would only be done for ops with a timestamp lower than where all members of a replica-set have been synced to. Then even adding a new member won't cause issues because it will be pulling after that point. The only thing that would be effected is non-slaves that poll the oplog. We could add a one-minute window where anything newer won't be madvise'd out. Alternatively we could disable this optimization for some period of time if we see any non-slave queries of the oplog.

Comment by Scott Hernandez (Inactive) [ 01/Aug/11 ]

What about secondaries pulling from other secondaries? One could pop up at any time, no?

I'm not suggesting this is a common case, but just raising it as a possible performance issue... but the os could cause this to be the case anyway. There is no good way to control this, without a lot more state of which node contains what data in mem.

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