6

There are two different, though I believe related, issues I have with how Windows Server 2003 handles processes's working sets.

First, there are GUI applications running on the console session whose working set is trimmed, when their top-level window is minimized. I know it's rather unusual to have server processes running with a GUI, but these are legacy applications doing important things that I cannot do anything about.

Second, there is a long running database server that allocates a lot of memory when a client connects, but doesn't touch that memory until another client connects. In the mean time, several days may pass and the operating system seems to think that is reason enough to trim that process's working set.

In both cases, there is plenty of physical RAM available (several GB more than the applications would need), so I would like Windows to not trim their working sets. Is there a setting to configure this? These are all third-party applications, so changing memory allocation or locking pages in memory aren't viable options.

PersonalNexus
  • 292
  • 2
  • 11
  • If you really have plenty of physical RAM you could consider disabling virtual memory, i.e., telling the system not to use a pagefile. That should solve your problem. – Harry Johnston Feb 27 '12 at 23:08

2 Answers2

2

The article that you posted has all the information you're asking for, though I understand it isn't what you want to hear.

First off, I don't know what your applications are or what they do or why their working sets not being trimmed is so important, or any of that other tangential information that might help you on your path to solving the problem that the behavior of the working set of the process is contributing to. It sounds to me like you have a poorly designed application that you have to support, and you're trying to alter the behavior of Windows to compensate for a poorly designed application. That's a crappy situation to be in, and I'm sorry.

That said, I'll try to answer your question:

You're describing a basic, fundamental mechanism in how Windows was designed. The default behavior of the Minimize button on a GUI's window is going to call ShowWindow(hWnd, SW_MINIMIZE) which trims the process' working set - end of story.

The writers of this poorly designed application that you're tending to could have chosen to intercept the WM_SYSCOMMAND message that occurs when a user clicks the Minimize window button and call ShowWindow(hWnd, SW_SHOWMINIMIZED) (which does not trim the WS) instead of ShowWindow(hWnd, SW_MINIMIZE), but they didn't. If you cannot contact the developers of this application and tell them to try again, this time with an actual server application, then you are stuck with this behavior.

Ryan Ries
  • 55,481
  • 10
  • 142
  • 199
0

In response to Harry Johnston, No.. not having a pagefile does NOT solve the issue...

Basically, there is NO WAY to stop windows from using a paging file... and when I say no way.. I mean NO WAY.. it's going to page to disk no matter how much you do not want it to.

If you tell ANY version of windows from Windows NT to 8.1 and/or their counterparts to NOT use a pagefile, guess what happens when you start to get near the point of running out of memory? (I've seen this happen on every desktop AND server version of windows)

Windows will appear to LOCK UP for about 5-10 seconds.. then come back and seem to work file.. what did it do? It just created temporary, emergency page file on the system volume where windows resides and will continue to use them until you reboot the system.

It will often do this RIGHT at the same time you get the error box popping up that you are running low on resources or memory (it should just say memory as system resources on 64bit windows are virtually unlimited now)....

In fact disabling the pagefile system will cause you more problems then not having one as many desktop and server apps EXPECT to see the page file and EXPECT to page out memory.. why? Simple.. two words: COMMIT CHARGE

When a program loads, it can either request memory as it goes, and hopes it is available.. or it can allocate up to 2GB of user mode memory on 32bit OS, 4GB for a 32bit app on a 64bit OS or up to 128TB for a 64bit on a 64bit OS

So If your server has 16GB of memory, and you load a database (and most of them tend to use their own memory mangement and caching internally), they will often allocate 1,2,4, or even 8GB of memory.... granted it may not NEED 8GB for a long time... but where do you think all that used memory is going to go? Windows doesn't want it sitting in physical ram and neither does the application. If the application is specially coded to swap out that unsed memory, it's going to crash. If it's not coded to do so... then it's up to windows to swap out that memory as it sees fit as it needs it...but without a pagefile.. you are WASTING RAM... in cases like this... NOT having a swap file will greatly reduce performance.

You don't need a HUGE swap file.. but if your server has 16GB of memory.. a 4GB swapfile is a nice lil number... It's not too big to where it will thrash the drive as it won't.. and windows can swap pages in an out as needed with little to no performance impact.

Adobe Photoshop is another ram pig... the 64bit version will snag 4GB of memory whether you have it.. or not...granted it's only going to use about 512MB to start with.. but if you start working with LARGE pictures, you can EASILY go over 4GB of memory use...

In the end it's better AND safe to have SOME form of paging file... even if it's only 512MB... plus 512MB guarantees you can at least get a minimal kernel dump and error dump if the system crashes. For a FULL dump, you need a page file on C: (or where ever windows boots from) equal to physical ram for a FULL memory dump (usually not needed and takes a great deal of time)

David Dutton
  • 149
  • 1