[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: |
|
||||||||
| 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 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"). |