Memory usage for Veeam B&R server

[Moebius]

I have a VBR server that is also a repository server (local storage and proxy for CIFS shares) and a target WAN accelerator.
The OS is Windows 2008R2.
The server has 32 GB RAM, 38 TB of local storage, and accesses 38 TB of NAS storage. The backups of the vSphere LUNs are made via SAN (double path FC link).

Lately (and apparently after the installation of the latest Veeam B&R patch) I started having resource problems. Even if I'm trying to run as few simultaneous jobs as possible, very often the Windows Task Manager shows next to 100% physical memory usage. At the moment, with only three active jobs (one backup job and two backup copy jobs, one that is verifying a vmdk and the other that is merging) the Task Manager shows 90% usage.
All this memory usage doesn't show up in the Process tab of the Task Manager, I only have one process that is taking 1 GB and other four that take more than 100 KB (sqlserver, VeeamAgent and tomcat).
RamMap shows a large Paged Pool size (13 GB) and a large Mapped File memory (13 GB), along with 5 GB of Process Private memory. I'm not familiar with the meaning of these entities. I would post a screenshot but don't know how to attach images here.
What is worse is that recently events 2004 (Resources Exhaustion Diagnosis Events) have started appearing in the Windows event log, as well as "Error: Insufficient system resources exist to complete the requested service" messages in the jobs statistics (not showing a warning sign though).

It looks very odd to me that a server with relatively low utilization is using up 32 gigabytes of RAM, failing jobs and throwing warnings in the Event Logs. I must have overlooked some very important settings, and I don't have the necessary knowledge to get deeper into the memory management tools and diagnostics.

Can anybody help me shed some light on this matter?

[PTide]

Hi,

Please refer to System Requirements

Windows itself consumes at least 2Gb if idle.

VBR console: +4Gb + 500Mb per job

Proxy service (can be disabled in case you deploy another one): +2Gb + 200MB per task (1 slot = 1 task)

Repository: +4Gb plus 2 GB RAM (32-bit OS) or 4 GB RAM (64-bit OS) for each concurrent job. May vary depending on your backup chain overall size.

WAN accelerator: +8Gb, however it behaves like all-you-can-eat sometimes when it comes to practice.

So RAM consumtion around 30Gb might be normal for all-in-one machine. If nothing has changed in your backup infrastructure except for an update installation prior to ram issue occurence then please open a case with support and post your case ID here - that's unnormal behaviour if an update turns the way how RAM is handled upside-down. Anyway, I'd suggest you to move your WAN and proxy to some dedicated machine.

Btw, what's the typical size of your backup chain?

[foggy]

Based on the math above, I'm getting 32GB for "one backup job and two backup copy jobs" even without counting WAN accelerator in: 5,5 (console) + 2,6 (proxy) + 24 (repository - remember, 4GB for each backup copy source and target data mover agent) = 32.

If the behavior is observed after applying Update 2, then this might be the reason, as it introduced target data mover metadata caching, which increases RAM consumption of each job assigned to repository.

[bertdhont]

Is there a way to disable target data mover metadata caching?

[foggy]

Yes, you can either use one of the options mentioned in the KB or use the registry value.