Ticket 229 - Include allocated memory in "scontrol show node"
Summary: Include allocated memory in "scontrol show node"
Status: RESOLVED FIXED
Alias: None
Product: Slurm
Classification: Unclassified
Component: Other (show other tickets)
Version: 2.5.x
Hardware: Linux Linux
: 5 - Enhancement
Assignee: Moe Jette
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2013-02-08 03:19 MST by Ryan Cox
Modified: 2013-02-12 05:17 MST (History)
0 users

See Also:
Site: BYU - Brigham Young University
Slinky Site: ---
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
Google sites: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
NoveTech Sites: ---
Nvidia HWinf-CS Sites: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Tzag Elita Sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed:
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this ticket.
Description Ryan Cox 2013-02-08 03:19:03 MST 
Currently "scontrol show node" shows the amount of configured memory for a particular node.  I would like to have it show the amount of memory that has been allocated, like CPUAlloc vs CPUTot.  I tried looking through the code to see where to add it but it's honestly a little hard following everything to see where that is even stored.

A different command is acceptable to.  Basically, I'm trying to create utilization graphs per feature and want to have the following information:
* CPUAlloc / CPUTot
* RealMemoryAlloc / RealMemory  (people may request 1 CPU but 100% of the memory, so count that as a whole node allocated)
* State
* Features
* NodeName
Comment 1 Moe Jette 2013-02-11 06:07:21 MST 
The only way to get that information today is by reading the node information, then reading the job information and doing the math (hardly convenient). We may be able to add this to our next major release - time permitting.
Comment 2 Moe Jette 2013-02-12 05:17:48 MST 
I have made this change in the Slurm version 2.6 code base (to be released in a few months). I would recommend against it, but if this proves critical to you the patch could be applied to Slurm version 2.5 with minor modification. The fix is here:
https://github.com/SchedMD/slurm/commit/3533f8221dcbab667b8f478b630165cbe2a9151f