Troubleshooting SharePoint Sluggishness
(Server Side Issues)

I’ve recently seen quite a few cases of “SharePoint Sluggishness”. When SharePoint is slow, it undermines productivity and can be frustrating to your SharePoint users. But how do you troubleshoot the issue to identify the underlying cause of the slowdown? In this post, we’ll offer some insight on troubleshooting techniques you can use to pinpoint what’s causing slow performance on your SharePoint site.

The first thing that should always be checked is your Server resource utilization. This is often the culprit, and very quick and easy to determine in most cases.

You’ve probably heard by now that most “SharePoint Sluggishness” can be traced back to SQL. While that’s true in most cases, it doesn’t really offer us much information about what is causing the stress to the SQL Server.

Typically, I check the Web Front End first. In doing so, I check the resource utilization, such as RAM and CPU. If nothing immediately jumps out, I do a quick check of the event viewer for errors such as “this thread was chosen as the deadlock victim” or “Resources unavailable to service this request”. Either of these responses will indicate insufficient resources. And if Web Front End is ruled out as the culprit, we then head over to the SQL Server.

*Please note that if you see the “this thread was chosen as the deadlock victim” error, in most cases even after resources become available, you will need to reset IIS to “jumpstart” this thread once again.

Now we check the SQL Server. We will check the same things as the Web Front End, such as RAM and CPU. If we don’t see any problems here, we should set up some performance counters for I/O and any possible Network Monitoring available. The I/O and Network Monitoring usually take time to accrue information, so we can start these now and move on in the event we need them later. If you feel confident about these, you can opt to skip the I/O and Network Monitoring, but this may require you to spend more time with this later should you not find the culprit in the following troubleshooting.

There’s one more server side possibility. The SQL Instance itself. This becomes especially important and can be the cause of a bottleneck if you notice your SQL Server’s RAM usage is running rather high, even during idle times.

To do so, we will open SQL Server Management Studio’s. Once this is open, we will check the maximum allowed RAM usage in SQL, as SQL will typically use all RAM allocated to it. We do this by right-clicking the SQL server in SQL Server Management Studio and selecting properties as shown below.  Now we select Memory and find the text box for “Maximum server memory (in MB):” We need to find a balance here, as if we allow SQL to be “uncapped” then the Operating System will not have enough RAM to operate efficiently, while “capping” this too low will result in a SQL bottleneck as SQL will not have enough resources to run efficiently. This will depend on your Farm’s configuration and needs, but typically about 2/3rds of the RAM on the server should be allocated for SQL.

Microsoft SQL Server Management Studio screenshot

If you still have not found a bottleneck, then it’s time to do one of two things:

  1. Check the I/O and Network Resource Monitoring that we setup earlier and look for problems there.
  2. Check the site itself for possible performance issues.

*Obviously if you do not find any problems reviewing option 1, then move on to option 2. 

Beyond server-side issues, occasionally there are “site-side” problems that can cause this behavior. I will follow up with how to troubleshoot “site side” problems that can cause sluggishness in my next post.

As always… thanks for reading!


**More information regarding I/O test that you can perform can be found here!

**More information over Network Monitoring can be found from your Network Monitoring hardware/software provider.

VN:F [1.9.22_1171]
Rating: 9.6/10 (7 votes cast)

About Eric Lough

Eric Lough (known as ELough) has sharpened his craft as one of Fpweb.net's trusted go-to guys on the Support Team. ELough focuses on trouble tickets, while at the same time expanding his knowledge of SharePoint configuration by actively participating in new builds and SharePoint events. Outside of SharePoint, you'll find him gaming (electronic or physical), being the IT guy for his family, or spending time with his daughter Kaylee, who also enjoys gaming on all platforms (especially Mario Bros. for the Wii at the moment). At 31 years old, ELough has spent most of his 20’s in the IT field and drifted into the SharePoint arena about five years ago. His CNS or ‘Networking’ background translated well to SharePoint as the platform emulates a “network” by communicating between various software on a large scale. This piqued his interest in both where SharePoint will go in the future and where it’s been in the past, and ELough’s mission is to know the beast inside and out.
This entry was posted in SharePoint Tips & Tricks and tagged , , , , , , , , , , , , , , , , . Bookmark the permalink.

3 Responses to Troubleshooting SharePoint Sluggishness
(Server Side Issues)

  1. Eric Lough says:

    @Steve Werner

    Hello,

    I checked your site and am impressed with the approach. Developing SharePoint solutions with an emphasis on cloud environments is an arena with massive growth potential, and will only become even more popular in the future. SharePoint 2013 is rumored to gear more towards this approach as well.

    As always, thank you for your replies!

  2. Pingback: How to Troubleshoot Slow SharePoint Performance - Part 2

Leave a Reply

Your email address will not be published. Required fields are marked *

Let's make sure you're human first: *