[SERVER-6748] linux kernel memory management strategy on mmapped MongoDataFiles (readahead) controllable from shell with madvise command per DB Created: 10/Aug/12 Updated: 06/Dec/22 Resolved: 14/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Pék Dániel | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | performance | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Assigned Teams: |
Storage Execution
|
| Participants: |
| Description |
|
Scenario:
In this scenario, I measured the following:
I made a little patch which makes it possible to set one of the MADV_SEQUENTIAL, MADV_NORMAL or MADV_RANDOM flags on a given database's mmapped MongoDataFiles. ); I was able to query with ~3MB/sec net, while I had only ~4MB/sec on the EBS storage. That was a big improvement in my case. I thought it worths to share this patch, if anybody ever has the same problem, it could help, or could be a good starting point. I tested it only on Ubuntu x86_64 for 1-2 hours, so care must be taken |
| Comments |
| Comment by Pék Dániel [ 10/Aug/12 ] |
|
Turned out, that it isn't the final solution, because on new MongoDataFiles the madvise setting won't have any effect. This setting should be persisted, and used as an open/create parameter of MongoMMF. Patch coming soon |