[SERVER-3433] Command to report %-in memory per namespace Created: 15/Jul/11  Updated: 06/Dec/22  Resolved: 18/Dec/18

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

Type: New Feature Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 4
Labels: caching, memory, mincore
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-9829 Add ability to separate data from ind... Closed
Related
is related to SERVER-8927 Add a new administrative command to p... Closed
is related to SERVER-3109 Expose index stats Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

Add a command which can report the % of the namespace (for both the data and all indexes related to a collection) which is currently in (mapped-resident/cache) memory. This can be added for reporting cache/memory efficiency and for debugging performance issues.

It could be called something like

{cacheStats: <ns>}

and report something like this:
{cacheStats: [
{<ns>:

{ percent: 20, graph: "XXXXXXX___0000_____XXXXXX..." ]}

Where percent is the percent in memory of the namespace, and a graphic (textual) representation shows which parts of the namespace are in memory.

Or a distribution is the number of the contiguous page blocks (which could tell you if you are accessing data randomly or in ranges, and should be cheap to calculate as you are walking pages ~ mincore).
distribution: [
4: 20000
25: 60
300: 4
...
]}}



 Comments   
Comment by Adam Flynn [ 14/Dec/12 ]

We built a tool to do something like this. Doesn't give distribution within a collection, but it'll tell you how much of each collection is currently in cache.

http://eng.wish.com/mongomem-memory-usage-by-collection-in-mongodb/

Comment by Grégoire Seux [ 15/Oct/12 ]

this would be great to understand the reason of page faults

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