Feature request: Additional virtual memory metric to Process Watchdog

[MikeM]

Hi,

I've been reviewing Process Lasso for the last couple of days and I must say I find it quite useful!
We run on our servers an in-house tool which has a subset of Process Lasso capabilities. I'm considering replacing this tool with Process Lasso and taking advantage of the additional features it has to offer.

However, there's one feature Process Lasso is missing which is critical for us: monitoring process' Virtual Memory Size and restarting it when it gets above a predefined threshold.
I assume adding this memory metric to the Watchdog should be pretty trivial.

Could you please advise whether this capability will be added to Process Lasso?

Best regards,
Mike

[BenYeeHua]

So I just check the status of the processes, it show that PL also don't show/monitoring the Virtual Memory Size of processes too.

I think we need this.
1.Showing/monitoring the Virtual Memory Size of processes
2.Let the watchdog support monitoring the Virtual Memory Size of processes.

[Jeremy Collake]

That's something I can add, though the 'Commit Charge' should suffice in almost all cases. The Commit Charge represents most of the virtual memory, excluding some shared memory pages and memory mapped files - in other words, everything that is exclusive to that particular process. It is arguably the best metric to indicate a process's virtual memory consumption.

[BenYeeHua]

That's something I can add, though the 'Commit Charge' should suffice in almost all cases. The Commit Charge represents most of the virtual memory, excluding some shared memory pages and memory mapped files - in other words, everything that is exclusive to that particular process. It is arguably the best metric to indicate a process's virtual memory consumption.

I see no difference between 'Commit Charge' and 'private bytes', are they the same?
And ya, the process that having the biggest Virtual memory(for me) is svchost.exe, that running with the SuperFetch service.

[edkiefer]

how big is the service , my biggest memory usage on service is approx 125mb

[Jeremy Collake]

On further thought, I believe my response should be:

Processes should be monitored against 'Commit Charge'. This is the best representation of virtual memory used by a process. In essence, 'Commit charge' should be considered *as* 'Total Virtual Memory'. The actual total virtual memory mapped to a process's space is, of course, considerably larger - but nobody uses that metric, and it's not very helpful since it includes so much memory that need not ever be committed to the virtual memory system, or is duplicated from other processes (both pages mapped to the same backing memory).

So, 'Commit charge' *is* 'Total virtual memory', for all intents and purposes, except technically speaking.

Further, no process can have a total virtual memory size, and not have some commit charge.

The working set, on the other hand, will vary depending on how much of the process is mapped into physical RAM.

[MikeM]

Thank you all for the responses!

Here's my situation:
We have a 3rd party program which we are required to run on our servers.
However, this program has a memory leak and when it reaches the max virtual size of 2GB (process is 32 bit), the program gets stuck and must be restarted.
Unfortunately, support for this program is well below par and we have to work around it at the moment, which is why we developed an in-house watchdog.
I would be more than happy to replace our internal tool with Process Lasso but it must support monitoring a process' virtual size in its watchdog.

Best regards,
Mike

[BenYeeHua]

However, this program has a memory leak and when it reaches the max virtual size of 2GB (process is 32 bit), the program gets stuck and must be restarted.

Ya, but I think the windows is 64-bit?
As LAA(Large Address Aware) software can using 3.x GB(before it crash), but with GC software(like Firefox) it will be slowing down while increasing the Memory usage of process/GC that need to process.

[MikeM]

Ya, but I think the windows is 64-bit?
As LAA(Large Address Aware) software can using 3.x GB(before it crash), but with GC software(like Firefox) it will be slowing down while increasing the Memory usage of process/GC that need to process.

Yes, the OS is 64 bit (Windows Server).
The 3rd party program is not capable of using 3GB and even if it was, it would only delay the inevitable of reaching max virtual memory usage and crashing.

[BenYeeHua]

Yes, the OS is 64 bit (Windows Server).
The 3rd party program is not capable of using 3GB and even if it was, it would only delay the inevitable of reaching max virtual memory usage and crashing.

So, did the devs that maintain the code of that 3rd party program finding a solution for it?
And this show up how important the support for the program.

[Jeremy Collake]

We have a 3rd party program which we are required to run on our servers.
However, this program has a memory leak and when it reaches the max virtual size of 2GB (process is 32 bit), the program gets stuck and must be restarted.
Unfortunately, support for this program is well below par and we have to work around it at the moment, which is why we developed an in-house watchdog.
I would be more than happy to replace our internal tool with Process Lasso but it must support monitoring a process' virtual size in its watchdog.

Monitoring against 'Commit charge' to restart the process should work perfectly. Commit charge is essentially virtual size, though not technically, it is the metric that should be used.

I can almost guarantee your in house tool uses Commit Charge.