I thought that it was based on the screenshot, but just to be sure. You should probably monitor the parameters and see if that's the problem first, but I'm guessing that it is. The 64-bit versions of Windows have been nortorious for this issue as long as they have existed. Basically they will simply eat all of your memory for read/write cache, even to the detriment of actual system I/O. This has been far less prevalent with 2008R2, but I found several software companies that claimed back as far as late 2010 that it was still an issue and linking to 3rd party tools, and now Microsoft itself has admitted that it can still be an issue under "certain circumstances".
My guess is they probably did something dumb/easy, like limit the read cache on a "per-process" basis, which would have addressed the most common issue (you could literally kill a server/Vista machine just by copying a single, very large file, especially if copying from a fast disk to a slower disk). If they limited it "per-process" then having multiple processes streaming I/O could still be an issue. It's just a guess at this point, but gives you something to go on.
Also, I didn't answer your question regarding peak working set. The "Peak Working Set" is the absolute maximum amount of memory that the process has used at any one point in time. Typically for Veeam we see this during the call to vStorage API to "mount" the volume and usually returns quickly to a fairly steady state. The "Working set" should be the total amount of memory that the process is using at that time. The "Private working set" is a subset of the "Working Set", as it's the part that is "unique" to that particular process while the working set includes memory that could potentially be shared with other processes.
It's actually very difficult to determine the actual amount of memory that a process is using, because, if two programs use the same DLL's and same API's, the memory is shared between then. That's why Windows defaults to displaying the "Private Working Set" because it's the only memory that's truly dediated to that process. But just because memory "can" be shared doesn't mean that another process is actually using it, and in the case of memory mapped I/O, it's rarely shared, although it could be.
So if you have two processes that show as follows:
Code: Select all
Name Working Set Private Working Set
aprocess.exe 143MB 76MB
aprocess.exe 128MB 63MB
How much memory would these processes actually be using? Well, obviously the private working set is 139MB, but what about the total working set? Without digging into the processes and determining the amount that is actually shared, is shareable but unique, and is memory mapped I/O, it's impossible to figure out. A reasonable percentage of it is probably .dll files that are already loaded in Windows memory, so that really would be shared, and at least some of the .dll files are probably shared between the two processes so it's not fair to account for them twice, but then some of it is likely to be mapped I/O unique to the process.
When it's all said and done, I seriously doubt that the Veeam processes are directly the cause of your memory issues, I just wanted to point out that you really have to dig into Windows pretty hard core to figure out how much memory is actually being used, and the numbers displayed by default in task manger do not include "shared" memory, so there's a lot of places for used memory to hide.