[SERVER-5987] doc_mem_monitor malfunction on Darwin Created: 01/Jun/12  Updated: 10/Dec/14  Resolved: 17/Sep/13

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: 2.1.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Eric Milkie Assignee: Mathias Stearn
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS


Issue Links:
Depends
is depended on by SERVER-6862 improve usability of aggregation sort... Closed
Operating System: OS X
Participants:

 Description   

For some reason, we did not implement SystemInfo::getPhysicalRam() on Mac OS. It returns 0 on that platform (and also on FreeBSD, incidentally).

The only consumer of this function is DocMemMonitor() in aggregation framework. It seems to be trying to limit how much physical RAM an operation will take, and uasserts if we exceed some threshold.

The comment for getPhysicalRam() says:

This should only be used for "advisory" purposes, and not as a hard
value, because this could be deceptive on virtual hosts, and because
this will return zero on platforms that do not support it.

So it sounds like we shouldn't be using this function to abort operations in aggregation. In fact, maybe we should just get rid of the function altogether, since no one else is using it.



 Comments   
Comment by Daniel Pasette (Inactive) [ 17/Sep/13 ]

this class is deleted.

Comment by Tad Marshall [ 01/Jun/12 ]

We also have a ProcessInfo::SystemInfo::collectSystemInfo() routine that gathers information, including memory size (aka "physical RAM"), for the hostInfo command. The Darwin version of collectSystemInfo (in util/processinfo_darwin.cpp at line 141) does collect "memSize", (aka "physical RAM").

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