SharePoint 2013 VM Guidance

SharePoint 2013 has been out for a little over a month now, and during that time I’ve had the chance to play with it in several environments and get a feel for how it performs.  The blog is a follow-on to my previous blog post regarding SharePoint and Virtual Machine (VM) Performance.  In that post, I broke down how to get the best performance out of a VM using VMware Workstation.  In this post, I’ll take a look at some of the changes in SharePoint 2013 that have lead to changes in guidance for how many resources to allocate to your SharePoint 2013 VM.

Worst Case Scenario

First off, let’s talk worst case scenario with a SharePoint 2013 VM.  This would be tons of the latest and greatest beta software:

• Windows Server 2012 Release Preview
• SQL Server 2012 Enterprise
• SharePoint Server 2013 Preview
• Visual Studio 2012 Release Candidate
• Office Professional Plus 2013 Preview with Visio, Project, and SharePoint Designer

Why is this the worst case scenario?  Because beta software is not optimized like production software.  Microsoft is famous for the amount of usage data they cull from users (they call this telemetry) and by using beta software you’re automatically opted into this usage collection (it’s in the EULA).  Anyway, the usage collection isn’t so bad, but the fact that its there means you’re going to lose performance.  Therefore, if you want a performant SharePoint 2013 Preview VM, ditch all but the must-have software (SharePoint 2013 and Visual Studio 2012).

Optimal Scenario

SharePoint 2013 Preview comes with a great deal of system requirements, many of which are handled by the prerequisite checker.  However, some that aren’t are the operating system and SQL server.  At minimum, you’re going to need Windows Server 2008 R2 with Service Pack 1 and SQL Server 2008 R2 with Service Pack 1.  If you’re building a development VM, you’ve more than likely got these ready to go, but I want you to be aware that these are the minimum requirements, which, unlike SharePoint 2010, are far more stringent suggesting that Microsoft isn’t messing around.
Anyway, ideally you’d have the latest versions of Microsoft’s software that aren’t in beta:

• Windows Server 2008 R2 with SP1
• SQL Server 2012 Enterprise
• SharePoint Server 2013 Preview
• Visual Studio 2012 Release Candidate

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

According to Microsoft’s minimum hardware requirements site, the minimum requirements for SharePoint Server have nearly tripled with a requirement for 4 cores and 24GB of RAM.  I have yet to find a laptop that can hold more than 16GB of RAM.  Fortunately, you can get away with slightly less processing power and RAM.
Using the configuration above, I would recommend at minimum allocating 2 processors (not cores) and 6GB of RAM to your SharePoint 2013 VM.  With that allocation, you can handle User Profiles, Search, and App hosting.  These are the most likely avenues for development and research since they carry the most new features.
Note: You could opt for SQL Server 2008 R2 with SP1 to get a little more performance, but you’d lose out on some of the new features in SQL Server 2012.

Handling Search

With that said, noderunner.exe will quickly become the bane of your existence.  Noderunner.exe is the new executable for the SharePoint 2013 search service.  Kind of like SQL server, by default it has no respect for the memory needs of other processes.  However, you can’t turn it off because Search is the most integral service application in SharePoint now, being tied into so many other capabilities and functionality.  Fortunately, there are some things you can do to reduce the impact of Search on your developer system without disabling it entirely.

Reduce the Search Service Performance Level

By default, when you spin up a new Search Service Application in SharePoint 2013, it’s performance level is set to Maximum.  This is great for a farm deployment where you can have a dedicated search server, but it’s really a drag on the performance of your single-server developer farm.  Fortunately, there’s a simple PowerShell command you can run that will drastically reduce the performance of your Search service:

Set-SPEnterpriseSearchService -PerformanceLevel Reduced

The PerformanceLevel tells the search service how aggressive to be when crawling, indexing, and querying for content.  Reduced is the minimum performance level, while Maximum is the maximum performance level.  There’s also PartiallyReduced, which is in between.

Limit the Memory Footprint of NodeRunner.exe

This change I don’t personally recommend, but I want you to know about it anyway.  There’s a configuration setting within NodeRunner.exe’s configuration file that will limit the RAM usage of a single process to a set number of megabytes.  This configuration file is located at: C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderunner.exe.config.  The configuration setting is under the nodeRunnerSettings node and it’s called memoryLimitMegabytes.  By default it’s set to 0, which stands for unlimited.  Whenever you change it, you’ll need to restart all of the noderunner.exe processes for the changes to take effect.  On a farm server with multiple servers running search, you’d have to change this setting on all servers, which is why I don’t recommend changing it.
Note: there is a known bug in the SharePoint 2013 Preview implementation of noderunner.exe that causes a memory leak.  Therefore, this setting will keep the leak from taking over your system.

Distributed Caching Service

SharePoint 2013 also comes with a new feature called the Distributed Caching Service.  This enables sharing cached data across a SharePoint farm in memory and is used heavily by the authentication and user profiles code bases.  I do not recommend turning this service off.  Although you can do it and not experience any adverse effects on a single-server environment, I had to restart my VMs every time I started or stopped it.  Therefore, I recommend that you leave it started and enjoy programming against it in your applications.

Summary

To summarize this blog, to run a performant SharePoint Server 2013 Preview VM, you’ll need to allocate 6GB of RAM and 2 processors to your system.  That system should be built on Windows Server 2008 R2 using SQL Server 2012 or SQL Server 2008 R2 with SP1.  You’ll then want to reduce the performance level of your search service using the provided PowerShell command.  This setup will result in a quick VM that provides all of the flexibility and capabilities that you’re likely to need.