Is there a way to tell Windows that it shouldn't swap out a particular processes' memory to disk?
Its a .Net windows service with fairly large memory usage. I got lot of physical RAM but the OS seems to move part of the process memory to the pagefile anyway.
You can use VirtualLock to prevent memory from being paged to disk, but I really think you're better off letting the OS manage the system's memory. It's pretty good at it, and I wouldn't second guess why the OS was swapping things to disk unless I really knew what I was doing.
VirtualLock by default will run out of quota in a hurry, even if you permission the user (by default the security policy setting of "Lock pages in memory" has no entries (not even admin)).
If you do configure this, you will need to set "Adjust memory quotas for a process" also.
This question is a bit ambiguous, what part of the VM space do you want to prevent from being swapped out? Heap/Stack/Module's?...?
Overall, one solution that I had used in the past, is to create a DLL with a large section which was READ + WRITE, unmoveable, you can also mark it EXECUTE and SHARED if need be, but then I would HeapCreate into that module's section, allowing me to use it as a heap.
You can look up the exact bit's to set here, IMAGE_SCN_MEM_NOT_PAGED looks like it would do the trick.
If you go through the process of marking all of your module's and sections with this bit, the Windows module loader will not charge a articular user quota or require policy settings be modified on each system you deploy your code. You will need to code in a special shim to provide access to the HEAP's you create into these NON_PAGEABLE dll's also.
It is a bit of work but it worked well for me in the past, I had the added requirement to share memory to multiple processes, which was based at the same address.
I would think the easiest thing to try would be to disable your page file entirely. But before this, if your using Vista/2008+ OS's, the swapping you see may be due to superfetch, which could be proactively "tuning" your system with the assumption that in the near future you need to use one application or another. Some other easy tasks would be to stop unused services like search, which could be indexing huge amounts of files, also you should go into your "task scheduler", which configures system tasks, by default there are a few dozen on most systems with default action's that will transmit all Dr. Watson dump's to MS, defrag your drive and a number of other possibly exceedingly memory intensive type operations.
You could reply with a bit more detail to get some better answers... but one other suggestion would be to simply purchase a large solid state drive and use that exclusively for swap, beware that these degrade over time in overall performance an size due to bad block mappings that are common with all existing SSD technologies.
I recently came across a codeplex project called "non-paged clr host", from their page:
Implementation From an implementation perspective, the non-paged CLR host uses the SetProcessWorkingSetSize, SetProcessWorkingSetSizeEx (on Windows Server 2003 and above) and VirtualLock APIs to ensure that memory allocated by it is locked into physical memory. Note that using the above APIs does not guarantee with absolute certainty that no paging will occur; instead, it minimizes the odds of it occurring to very exceptional scenarios. In some load tests we have conducted, even when the system as a whole was hogged by lack of physical memory, no page faults were observed in the process using the non-paged CLR host.
Are you sure that the pages in question are being evicted from memory? It's possible that the VM subsystem is proactively writing dirty pages to disk, without eviction, so that potential future allocations have lower latency.
Also, if the system is doing a large amount of IO, it may be better for performance to use the memory in question for buffers rather than application data, as described by Martin Pool