Had an interesting situation today on an old FileServer that’s still on Server 2008 R2 and only has 4GB of RAM.  While BackupExec is doing a full backup, the server absolutely crawls and becomes sluggish for users.  I struggled to RDP to it to investigate – it kept timing out.

Here’s what I eventually saw in Task Manager:


As you can see from the bottom of the window, Physical Memory is 91% used but with the processes sorted by memory use, the greediest is merely the AntiVirus with not even a quarter of a GB consumed.

The Performance tab was not much more revealing:


Here you can see that the total Commited RAM was not even 1.5GB of the 8GB limit (physical RAM + paging file).  Still though, you can see the RAM is well and truly taken up by something.  Incidentally, network traffic was minimal – indeed the backup was struggling at a slow speed.

Next stop was Sysinternals’ Process Explorer’s System Information window:


This reveals (at bottom left) that there is nearly 3GB of physical RAM used by the cache.

Finally, I loaded Sysinternals’ RAMMap:


This shows quite clearly that the RAM is used by an entry labelled “Metafile”.  This refers to NTFS Metadata such as the MFT (Master File Table) amongst other things.  Given that a 1TB data volume was being backed up, I guess it’s not surprising that so much NTFS Metadata is being accessed.

I found online that you can verify the size of the MFT using fsutil.exe:


Note the line “Mft Valid Data Length”.  You can convert that to decimal by entering into Windows Calculator.  I couldn’t bring myself to screenshot the awful Mickey Mouse App version on Windows 10, so here it is on the server:


After entering Programmer mode and selecting the Hex radiobutton, you type in the value and then click Dec to convert it to Decimal.


That gives a value which when converted from bytes equates to about 2.3GB for the MFT alone.

Obviously, we have to feed this server more RAM and see how it gets on…!