Idea Details

CDM memory top processes on total memory (physical and swap)

Last activity 05-31-2019 02:19 AM
RHaigh's profile image
12-13-2017 09:36 AM

The current CDM v6.20 only allows the top processes to be sent on the alarm for physical memory thresholds this isn't much use in the real world in a lot of instances like MS SQL which will by default use all the available physical memory thus alarm constantly, hence therefore why "memory usage" (probe GUI actually pagefile in CFX file) is used.

 

The support case was closed for this "as its working as design" which maybe so but not in the real world.

 

Parameter

memory_usage_alarm_includes_processes = 5

 

      <pagefile error> overwrite
         active = yes
         threshold = 90
         description = Pagefile usage above error threshold
         message = PagefileError <- "Processes" here
      </pagefile error>
      <pagefile warning> overwrite
         active = no
         threshold = 50
         description = Pagefile usage above warning threshold
         message = PagefileWarning <- "Processes" here
      </pagefile warning>
      <physical error> overwrite
         active = no
         threshold = 95
         description = Physical memory usage above error threshold
         message = PhysicalErrorProcesses
      </physical error>
      <physical warning> overwrite
         active = no
         threshold = 85
         description = Physical memory usage above warning threshold
         message = PhysicalWarningProcesses
      </physical warning>


Comments

03-06-2018 05:27 PM

I just stumbled across this issue too. 

 

I can't agree emphatically enough with the statement "isn't much use in the real world". 

 

It's been almost fifty years that we've had computers with RAM and disk and an OS that allows one to extend the other. Why, in 2017, a decision would be made that there's no value in knowing what processes are using a memory resource when the disk portion of that memory system fills or when the combined RAM and disk memory fills baffles me.

 

And of the three, the physical RAM is the least important. If you've sized the system correctly you always want physical RAM to be full. Otherwise you are just wasting money.

 

Like  RHaigh alludes too, you put SQL server on a database system and you want the free physical memory to be virtually zero - you want every bit of RAM for cache available for the database. What you want to know is when you run out of swap/pagefile on that system because that predicts the failure. You already know that MSSQL is at 95% of your RAM - alarming off that is meaningless. You need to know what is using the rest of it and growing swap.

 

-Garin