SharePoint 2013 e Dynamic Memory

La Dynamic Memory di Hyper-V è sicuramente una feature interessante in quanto permette una gestione oculata della RAM disponibile sull’host di virtualizzazione, ma prima di utilizzarla occorre eseguire valutare se i servizi e/o il software che la VM erogherà sno compatibili con tale metodo di gestione della memoria. Avevo infatti già fatto nel post SQL Server 2014 e Dynamic Memory alcune considerazioni sul fatto che per VM con SQL Server 2014 che debbano gestire elevati carichi di lavoro è meglio non  utilizzare la Dynamic Memory.

Un’altro scenario in cui la Dynamic Memory non va utilizzata e non è neppure supportata quando la VM eroga servizi SharePoint 2013 come indicato in Use best practice configurations for the SharePoint 2013 virtual machines and Hyper-V environment:

Configure the memory for the virtual machines

Configure memory on a virtual machine as you typically do for an application that runs on a physical server. The memory allocation must be sufficient to reasonably handle the load at ordinary and peak times. For SharePoint virtual machines, insufficient memory is the main cause of performance issues.

Before you install and configure the virtual machines on a Hyper-V host computer, calculate how much memory is available for the virtual machines. The root partition must have sufficient memory to provide services such as I/O virtualization and management to support the child partitions. For SharePoint products, we recommend that you allow a minimum of 4 GB of RAM for overhead on a Hyper-V virtualization host computer.

After you factor in the 4 GB RAM reserve for the virtualization host, configure the virtual machines to use the remaining memory.”

Dynamic memory

Windows Server 2008 R2 SP1 has the option of configuring dynamic memory (with a minimum value and maximum value) for virtual machines.

We do not support this option for virtual machines that run in a SharePoint 2013 environment. The reason is that this implementation of dynamic memory does not work with every SharePoint feature. For example, Distributed Cache and Search do not resize their caches when the allocated memory for a virtual machine is dynamically changed. This can cause performance degradation, especially when assigned memory is reduced.”

Per maggiori informazioni in merito alla Distributed Cache in SharePoint Server 2013 e alla Memory Allocation dei servizi della Distributed Cache si veda Plan for feeds and the Distributed Cache service in SharePoint Server 2013:

“The Distributed Cache service’s memory allocation for the cache size is set to a default value of 10 percent of total physical memory when SharePoint Server 2013 installs. An administrator can change the memory allocation for the Distributed Cache service by using the Update-SPDistributedCacheSize cmdlet. The Distributed Cache service can be assigned a maximum of 16GB of memory per cache host in the cache cluster. We recommend that you reserve 2 GB of memory for other services that are running on the server, and assign the remaining memory to the Distributed Cache service.”

“Windows Server AppFabric 1.1 can cause high memory usage on the operating system level. This affects the Distributed Cache Service so if you allocate 16 GB of memory you should have at least 34 GB of memory on the Distributed Cache server. This includes 2 GB of memory reserved for the operating system.”

“On a server that has more than 16 GB of total physical memory, allocate a maximum of 16 GB of memory to the Distributed Cache service. If you allocate more than 16 GB of memory to the Distributed Cache service, the server might unexpectedly stop responding for more than 10 seconds.”

“When planning for developer workstations, the developer’s workstation should have a minimum of 32 GB of total physical memory. On developer workstations, SharePoint Server 2013 is installed as a single server deployment. This means that the Distributed Cache service is deployed in collocated mode. In collocated mode, there will be competition for memory resources. To manage memory resource allocation, a developer can shut down any services that are not used, or they can periodically restart SQL Server.”

“The Distributed Cache service can run on either a physical or virtual server. When using virtualization, do not use Dynamic Memory to manage shared memory resources among other virtual machines and the Distributed Cache servers. The memory allocation for virtualized Distributed Cache servers must be fixed.”

Concludendo come riportato nel post Certain Microsoft SharePoint Server 2013 installation scenarios are not supported di Stefan Goßner (Senior Escalation Engineer for SharePoint Products and Technologies) l’installazione di SharePoint 2013 in una VM che utilizza Dynamic Memory è uno degli scenari non supportati.

Inoltre come riportato nel post SharePoint 2013 with distributed cache and dynamic memory non è solo la Dynamic Memory in Hyper-V a non essere supportata per il corretto funzionamento dei servizi della Distributed Cache, ma la gestione dinamica della memoria in generale indipendentemente dall’ambiente di virtualizzazione utilizzato:

But what is about VMWare?

Caching services are used to improve performance because these services are optimized to work with the amount of memory installed on a server. In case the memory will vary during the uptime of the server, there might be a need to also implement those features into a Caching-Service. That makes no sense because of the nature a Caching Service has.

In other words our SharePoint product group cannot support scenarios when Distributed Cache is needed/running and someone has concerns about performance or stability because of Dynamic Memory configuration in any Virtual Environment.

The best way for a customer to make this guarantee is to set the VM sizes (static memory) of the guests such that their sum is less than the memory available on the physical machine, i.e. don’t use the overcommit feature or dynamic memory.