Include- for Windows OS (Pagefile) utilization in your RAM sizing . Also in the Linux OS space (Swap usage) - "RAM sizing , stack-improvement"

When I review size down actions related to a VM running Windows OS / RAM usage I find that I disagree with some of those size down actions b/c they don't factor in Page file usage isn't factored into this decision . A hypothetical example of this that I see is as follows = I see a VM that has a Turbo size down RAM size action (-2GB RAM). When I use other tool to look at what the PF usage of a 2GB page file is I see page file usage running at lets say 80% .  So with this info I know that if I reduced RAM by the suggested -2GB and the page file is 2 GB in size and is running at 80% if I did that RAM size down action = the PF usage would be at 100%+ usage at some point there after . The page file running at 100% or near will start to give processes/request OOM error and not launch/execute ( Want to ensure Turbo size down actions won't cause OOM errors to not allow processes to execute= ***an issue***) .The same thing applies to Linux OS running VM's in the Linux "world" its called Swap usage , basically functions the same as the windows/page file mechanics listed above. FYI - Dynatrace does collect page file usage (they call is Swap usage)  so could easily  "stitch"/collect page file usage from entities that have DT collecting on them. In short want to look at what we can do to get a better "stack" for more accurate RAM size down actions that will eliminate the high probability or OOE errors  due to maxed out page file usage.