control a process' private bytes usage.....

Started by 4EverMaAT, January 18, 2016, 06:25:28 AM

Previous topic - Next topic

4EverMaAT

Is it possible to trim or control the usage of a process' private bytes?  I had a situation where an application had about 20MB in Private Working Set, but 2000+MB in the Private Bytes!  I found out later this might have been the cause of not being able to login via rdp as the commit charge peak was reached (there was about 600MB free RAM, but the commit charge was apparently full).

So I'd like to know if there is a way to control a process' private bytes so that no one rogue process can affect the whole system. 

So far I've come up with:
http://stackoverflow.com/questions/192876/set-windows-process-or-user-memory-limit  recommendation of Windows Job Objects, and
http://blogs.technet.com/b/mrsnrub/archive/2009/12/08/windows-system-resource-manager-wsrm-does-exactly-what-it-says-on-the-tin.aspx.

But I wanted to see if process lasso has a solution or any thoughts on this.  Win2008R2 Sp1 64 bit, 2.5GB RAM, Quad core processor,


edkiefer

#1
Quote from: 4EverMaAT on January 18, 2016, 06:25:28 AM
Is it possible to trim or control the usage of a process' private bytes?  I had a situation where an application had about 20MB in Private Working Set, but 2000+MB in the Private Bytes!  I found out later this might have been the cause of not being able to login via rdp as the commit charge peak was reached (there was about 600MB free RAM, but the commit charge was apparently full).

So I'd like to know if there is a way to control a process' private bytes so that no one rogue process can affect the whole system. 

So far I've come up with:
http://stackoverflow.com/questions/192876/set-windows-process-or-user-memory-limit  recommendation of Windows Job Objects, and
http://blogs.technet.com/b/mrsnrub/archive/2009/12/08/windows-system-resource-manager-wsrm-does-exactly-what-it-says-on-the-tin.aspx.

But I wanted to see if process lasso has a solution or any thoughts on this.  Win2008R2 Sp1 64 bit, 2.5GB RAM, Quad core processor,
Hi, First thing nothing you can do to fix a bad programed app from external (user point view).
I am not expert on this, but AFAIK commit size per app = private bytes , have you tried watchdog setting size to trim virtual memory size no greater to a value and trim the commit memory type.
Not sure that is going to fix issue but it may help a bit.
Bitsum QA Engineer

4EverMaAT

Quote from: edkiefer on January 18, 2016, 07:31:36 AM
Hi, First thing nothing you can do to fix a bad programed app from external (user point view).
I am not expert on this, but AFAIK commit size per app = private bytes , have you tried watchdog setting size to trim virtual memory size no greater to a value and trim the commit memory type .
Not sure that is going to fix issue but it may help a bit .

So there is an option to trim the virtual memory and trim the working set only with watchdog.  What exactly constitutes the 'virtual memory' and 'trim virtual memory' here with this option?

edkiefer

#3
You can trim the memory used by a process in any of those listed memory type as trigger point.

Ok, example say you don't want your X app going above 100mb , you set process name accordingly, for= virtual memory, greater than= 100mb, for= 15sec , then= trim VM, working set.

Best I can say is try it, it does work.
Bitsum QA Engineer

4EverMaAT

Quote from: edkiefer on January 18, 2016, 04:38:04 PM
You can trim the memory used by a process in any of those listed memory type as trigger point.

Ok, example say you don't want your X app going above 100mb , you set process name accordingly, for= virtual memory, greater than= 100mb, for= 15sec , then= trim VM, working set .

Best I can say is try it, it does work .
Can you trim the private bytes?  Or is it only the working set?

edkiefer

You could pick commit but it will not work good for what you want.
The best setting is working set for what you want
Bitsum QA Engineer

Jeremy Collake

No, it is not possible to trim Private Bytes. It is a fundamental metric representing the amount of private virtual memory the application has allocated.

Unlike the 'working set', it does not go up/down depending on how much is in RAM. Only the working set (which includes the private working set) can be externally trimmed.

Everything else is dependent on the application, and you can not do anything about it from the outside - e.g. certainly can't deny it virtual memory allocation requests.
Software Engineer. Bitsum LLC.

4EverMaAT

Quote from: Jeremy Collake on January 18, 2016, 08:24:30 PM
.......
Everything else is dependent on the application, and you can not do anything about it from the outside - e.g. certainly can't deny it virtual memory allocation requests.

That was what I was afraid of.  I wanted to either trim it, or cap the amount of virtual

I suppose I could set the watchdog to restart the app.  But 2 problems with that:
1) watchdog currently does not have path-specific app searching.  So all apps with the name 'application.exe' will have the watchdog applied to it.  Great if there is only 1 instance of that app.  But what if you have several instances in different install folders running simultaneously?

2) I try to avoid restarting an app because I lose some of the data that must be generated real-time.

But I can settle for #2 if you can fix #1 so that I can ignore apps in a specific folder,or only apply rules to apps in a specific path.  I would like both actually.  A blanket rule that could apply to several instances of the same-named executable, and then create exceptions for a few of them.

BenYeeHua

Well, Private Bytes means the software's own data, it can be inside the RAM and also Page File.
Based on your working set, it is just loaded but not being used, so after you TRIMed it, it just getting put inside the Page File.

For commit charge, if you means that one showing inside the Windows Task Manager, it is RAM+Page File size, you can just increase your Page File size or just set it as Auto size(managed by System) and stop worrying about it. :)
---
So ya, I think the real solution is just telling the dev to unload that data when it is not needed, unless it is not some files that will be cached by system. ;)