[SERVER-22976] Include system physical memory in serverStatus Created: 05/Mar/16  Updated: 22/Jun/16  Resolved: 22/Jun/16

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

Type: Improvement Priority: Major - P3
Reporter: Bruce Lucas (Inactive) Assignee: Mira Carey
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Sprint: Platforms 16 (06/24/16)
Participants:

 Description   

When diagnosing an issue we frequently have to go back to the customer to find out how much physical memory is on the machine, for example by collecting mdiag, or simply by asking. This delays diagnosis and creates extra work for us and for customer. It would be helpful to include system memory as part of serverStatus, so that it would be present in FTDC (>=3.2) or manually collect serverStatus timeseries (3.0). This information is already collected and readily available in the SystemInfo object.



 Comments   
Comment by Bruce Lucas (Inactive) [ 22/Jun/16 ]

Agreed, closing.

Comment by Mira Carey [ 21/Jun/16 ]

bruce.lucas, is mark.benvenuto's argument persuasive to you?

As it is, it sounds like there are ways to get the info we need via hostInfo, that it's in ftdc and that putting it in serverStatus is possibly a bad idea. Which would lead me to close as wontfix.

Thoughts?

Comment by Mark Benvenuto [ 07/Mar/16 ]

serverStatus is not the best place for this since it never changes during the lifetime of the process. hostInfo already includes physical memory information though:

> db.runCommand("hostInfo")
{
	"system" : {
		"currentTime" : ISODate("2016-03-07T06:45:09.314Z"),
		"hostname" : "localhost",
		"cpuAddrSize" : 64,
		"memSizeMB" : 16384,
		"numCores" : 4,
		"cpuArch" : "x86_64",
		"numaEnabled" : false
	},
...

Finally, ftdc captures hostInfo on every MongoD startup, and every file rotation.

Comment by Mark Benvenuto [ 06/Mar/16 ]

We should also ensure that when running in a container we either report the container limit instead of physical ram, or we report both.

With SystemD and other container tools that use cgroups on Linux, this could be important to get the actual memory limit. See https://lwn.net/Articles/529927/

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