<> wrote ...
>I have a commericial application that is going memory crazy. Given the
> right conditions it will start allocating memory until the system
> comes to a complete halt.
>
> Is there any way to impose process quotas on the amount of page file
> space or physical memory so that I can force the appliation to crash
> rather than my whole system to seize up.
Hi Faceman,
The answer is kind of "yes and no". Under the basic Windows process model,
an application can keep allocating memory as much as it likes. A
*well-behaved* Win32 application will make a distinction between "reserving"
and "committing" memory - it sounds like the app you're using is committing
memory when it should be only reserving it. This is a pretty common
programming error (unfortunately). When teh memory is reserved it will be
shared equably with other processes. If an app commits teh mmeory, it is
more or less saying "I absolutely must have this memory to run" so teh OS
gives it memory in preference of other processes which merely say "Gee I'd
like some memory, if you can spare it" to the OS.
Window 2000 introduces a new Win32 process primitive, the "job object". The
job object can contain one or more than one processes; and it can have
limits on the memory and the CPU time available to the collective
processes.Depending on how you create the job object you could, for example,
tell a process to shut down, if it hits a certain memory limit you specify.
So this sounds liek just teh facility you need, right? Well, now the bad
news. There's no command-line or GUI tool in Vista which actually exposes
the job object to the user or system administrator. If you don't mind a
little C/C++ programming, it is pretty easy to create a short "wrapper" for
your application, which creates a job object, sets a memory limit, starts
the process, then attaches teh process to the job object. You could do this
in, say, 20 or so lines of code ... it's the kind of program I'd be game to
write myself (and I'm a really bad programmer).
I had an idea that you could also access the job object through some
facility of Windows Script Host, but I can't find any examples on the 'Net.
So maybe I was just dreaming that ...
Windows Server 2003 has exactly the tool you want - Windows System Resource
Mamanger (WSRM). What's better, you could download and install the 2003
version of WSRM onto an XP machine, and it would run fine. This gives you a
great tool with very powerful features to control job execution, for Server
2003 and for XP. Unfortunately the 2003 version of WSRM will not install on
Vista. There is an updated WSRM in Windows Server 2008, and I expect that
this new version will run on Vista, too - but at present, there's no
separate package of WSRM which you can install on Vista; it's kind of
Built-in to Server 2008 and can't be transfered to another machine. Maybe
Microsoft will release a stand-alone WSRM for 2008/Vista, after Server 2008
ships - this would be the same as what they did for WSRM on Server 2003.
With a little ingenuity, you could also write a short-ish WMI script which
monitors the memory used by the application and if it reaches a certain
level, shut down the application. There are some sample scripts to get you
started, here:
http://msdn2.microsoft.com/en-us/library/aa394599.aspx
Overall, your best bet is to contact the vendor of the commercial app and
get a fix from them to correct its behaviour. 2nd best solution will be to
use WSRM, if or when it becomes available on Vista. Third solution would be
to write a WMI script to monitor memory use by the process and forcibly
terminate it, if it get too crazy. The last resort would be to write a
simple C++ program, a job object wrapper for the commercial application, to
give memory limits to the process. Just to repeat, this would not be a major
programming project - any semi-literate C/C++ programmer could write such
and debug a program in an afternoon (and still have time to surf the web a
bit before leaving work).
Other folks may have extra ideas for you ... hope this helps a bit.
--
Andrew McLaren
amclar (at) optusnet dot com dot au
Similar Threads
Linear Mode
