1

Our SharePoint site is going extremely slow, especially when trying to delete items - majority (90%) of triggered Workflows fail and give Error Occurred - Editing or adding data is a nightmare.

What could be causing the issue ? Any troubleshooting steps to follow ? Our memory usage is between 70 and 80% and won’t lower even if we stopped loading or editing large volume of data. Is there a possibility to figure out where the traffic is coming from ( Site/ crazy Workflows)?
We have around 30 Lists ( contain average of 15000 items each).

  • Can you elaborate on the details? Are you referring to the entire sharepoint server? site collection? site? page? specific lists? To the "answer", from Matthew, are you seeing anything in the SP Logs? Event Viewer? ULS Logs? Do you have List Thresholds defined? If lists only, do you have any indexes defined? What's your hardware look like compared to the required hardware for SP 2010? Do you need to update the hardware? – Quinn Johns Mar 16 '17 at 20:59
1

There are couple of things you can check.

  • Check the ULS logs and see on which operation it is spending too much. Here is good article, how to do performance filter in ULS logs.
  • You can also check the space on the SQL server, Performance of Memory and CPU
  • sometime, it is simply the server's are overloaded and hardware not meet the capacity requirement. You may need add more memory.
  • Check the IIS logs to examine the traffic
  • Enable the Caching, sometime help the performance issue.
  • Check your List view threshold, if it more than 5K then it can cause the performance issue
  • Check the Workflow history list, sometime this contains millions of data which cause the performance issue
  • Also avoid the large insertion / deletion / editing operations during the peak hours.
0

I concur with Waqas on the pointers he provided, however, in my 15 years in troubleshooting SharePoint performance problems, nine out of ten times it ends up being SQL server. You mentioned you're doing mass data loads. I would start by checking the Auto Grow settings on your Content Database in SQL Server. By default SharePoint sets this to 1MB. This is orders of magnitude too small for SharePoint. Even if you modify your Model database to have increased settings, SharePoint still ignores that and uses 1MB. I recommend changing that to 1GB. This will reduce the number of auto grows that SQL had to do this improving SharePoint performance. Probably the best first step is to pull a list of heavy queries in SQL. From there you'll be able too see if a particular list is a common culprit and then look at the statements to find fields that could use indexes to improve performance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.