Monitoring Cube Performance and Usage - Expert Cube Development with SSAS Multidimensional Models - page 321

There has been a lot of discussion over the years about what the "right"
size for the Windows paging file is, and there have been a number
of suggestions made that are simply wrong. There are, for example,
several formulas around based on the amount of physical RAM, and
the most common uses what is reported in the Virtual Memory dialog
box, which is 1.5 times the physical RAM in the system. However,
most of these suggestions are baseless and inherited from an era where
the RAM of a server were measured in hundreds of megabytes.
Today we might have tens of gigabytes of RAM, and paging 1.5 times
this amount of data seems crazy, even just for the time required to
read and write that much data (we are talking about minutes, not
seconds here). There are only two conditions that justify a big paging
file size: if we need a full memory dump in the event of a system
crash/blue screen, then the size of the paging file must be at least the
amount of physical RAM; and if a kernel memory dump is required,
then a variable amount of paging file is required, up to the amount of
physical RAM, but generally lower than that.
Where only a small memory dump is required as a result of a
blue screen, the size of the paging file only has an impact on the
performance of the dump. Having a few gigabytes should be enough
even on servers with tens of gigabytes of RAM. If you want to work
out what a good custom size of the paging file would be for your
server, we suggest reading http://tinyurl.com/PagingSize
and http://support.microsoft.com/kb/889654 , and also
http://tinyurl.com/VirtualMemory , which is a more complete
description of virtual memory, written by Mark Russinovich.
Thus, we have a paging file and we need to optimize its use; ideally Analysis
Services should not use it at all. If Analysis Services were the only process running
on the system, it would be sufficient to set its memory limits to a value that doesn't
exceed the amount of physical RAM of the system. In fact, the default settings of
Analysis Services are below this limit, but they don't take into account that other
memory-hungry processes may run concurrently on the same machine. For example,
it's quite common to have both SQL Server and Analysis Services running on the
same machine. Think what would happen when we processed a cube, which of
course would mean that Analysis Services would need to query the fact table in
SQL Server: both services require memory and paging to disk could be unavoidable.
There is a difference between SQL Server and Analysis Services in terms of memory
management, in that SQL Server can adapt the amount of virtual memory it requests
from the operating system to the amount of physical RAM available to it. Analysis
Services is not as sophisticated as SQL Server and does not dynamically reduce or
increase the size of its requests for memory to the operating system based on current
available physical memory.