[SERVER-2126] test use of madvise to improve performance of the replication oplog Created: 20/Nov/10  Updated: 10/Dec/14  Resolved: 07/Mar/14

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

Type: Improvement Priority: Minor - P4
Reporter: Dwight Merriman Assignee: Unassigned
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-3509 madvise(DONT_NEED) portions of oplog ... Closed
Related
related to SERVER-9335 prefetch/fault-in the tail of the opl... Closed
Participants:

 Description   

using madvise for local.oplog.rs (or log.oplog.$main) may improve performance, as we know the access pattern. for example this could save waste of the file system cache if the system knows in some cases it won't be needing the data again

specifically:

(1) MADV_SEQUENTIAL might perform better in general

(2) MADV_DONTNEED might make sense on a replica set non-primary. on a non-primary, no one is reading its oplog, we are just writing to it.

if these were tested and performance was the same, I would be in favor of using, as they probably make caching smarter, if anything.

http://linux.die.net/man/2/madvise



 Comments   
Comment by Eric Milkie [ 07/Mar/14 ]

We now madvise_sequential all capped collections

Comment by Dwight Merriman [ 21/Nov/10 ]

yes perhaps.

Comment by Testo [ 21/Nov/10 ]

how about MADV_WILLNEED? Would it help if you read ahead oplog and find out which block of data you would need and schedule it in advance before actually read/update it? It might help if the replication is falling behind.

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