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.
If you still have not found a bottleneck, then it’s time to do one of two things:
- Check the I/O and Network Resource Monitoring that we setup earlier and look for problems there.
- 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.