SharePoint Performance


Published on

Presentation around several tips & trick to improve SharePoint (on premise) performance, mainly by tweaking the SQL databases.
Download the ppt for fun animations !

Published in: Software, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • This presentation is meant to also be a nice “toolbox” for both current and new SharePoint deployments. There are a lot of reference links included in the presentation, as well as descriptive comments, like this. Although most options mentioned in this presentation are appropriate for MS Sql Sever 2008 R2, they will also work on older and newer SQL Server editions. This presentation is a collection of best-practices and performance tips which are scattered all across the web. This information is by all means not complete and will be a “work in progress” for the coming years. November 2013, Jeroen Schoenmakers
  • A separate database for each “silo” or “section” in the intranet. This prevents having 1 big bucket that becomes slow and difficult to backup / restore / maintain.
  • When we put all the work in the front end and ignore the back end.
  • Fill factor:MAXDOP: When SQL Server runs on a computer with more than one microprocessor or CPU, it detects the best degree of parallelism, that is, the number of processors employed to run a single statement, for each parallel plan execution. You can use the max degree of parallelism option to limit the number of processors to use in parallel plan execution. Very short it comes down that SQL Server can utilize the amount of processors that are available to execute the queries in parallel and thus very efficiently. Now this does sound like a very cool nifty feature eh? It actually is.. however, sometimes SharePoint tries to produce some ad-hoc SQL queries where SQL Server has no clue what the most optimal path could be and thus it could lead to bad performance when it tries to utilize all the processors that are available. Furthermore, the PG has tested a lot with variable settings and came to the conclusion to NOT to use MAXDOP  is the most stable and performing way. And, when MAXDOP can be helpful, it is stated in the stored procedure itself.  
  • To create 64 K allocation unit:DiskpartList diskSelect disk <disknumber>create partition primary align=1024assign letter=<DriveLetter>format fs=ntfs unit=64K label="<label>" nowait
  • Click on the “ref” link for reference material!
  • Don’t use autoshrink and don’t use “Auto-Repair” in the SharePoint Health Analyser report !!: DBCC CheckDB as part of your backup / maintenance plan. If you don’t check the database integrity, SQL Server will backup corrupt databases and tell you the backup is successful ! Only when you restore the database, you’ll find out the database is corrupt and actually not restore-able !!! Of course you’ve been backing up this corrupted database for 2 months now, so there IS NO current backup to restore from !! I’ve seen this happen in production environment, be aware of this glitch ! (Run DBCC Check DB on off-hours, it will also keep your DB’s fast !)
  • Where to look when there is a performance issue. These things should be benchmarked so that you can identify potential issues easily. Of course, some of these are already described in the previous slides to prevent them from happening !
  • Ask for help: IW Yammer community, SPYam Yammer community, SQL DBA forums, #SP2013, #SP2010, #SQLHelp
  • Before you know it you discovered a company-wide network issue, or SAN issue or virus; Always be ready for escalation. Example of things might blow-up very quickly is that I once was working on a performance issue, I discovered an old trial version of a 3rd party product still in production. I used the uninstall that came with the software, it removed a (later to be) Shared SharePoint component, resulting in the famous “configuration database not found” error on a white screen.. Check: for more details !
  • SharePoint Performance

    1. 1. cis October 2013 Jeroen Schoenmakers N E W H O R I Z O N S SharePoint Performance
    2. 2. Who am I ?  Jeroen Schoenmakers aka  @Shuwi  Linked in  15 years SQL DBA & .NET Dev experience  5 Years SharePoint experience  MCITP,MCTS 
    3. 3. Agenda (Slides will be available)  Who am I  Setting up SharePoint, performance gains  Preventing future performance issues  Optimize your current deployment  Trouble-Shooting SharePoint Performance issues  When do you have an issue ?  How to solve the issue ? (Methodology)  Case: Extremely slow uploads on extranet
    4. 4. How SharePoint uses SQL Server  One configuration DB per farm  Each web app has one or more content DBs  Container for site collections (scalable, SharePoint limits)  All SharePoint content, including files, is stored in content DB (Out of the box)  Service application databases  Search databases are usually most important when optimizing.
    5. 5. Example: Ivanhoe Production Farm (intranet)  Use master; select name from sys.databases 64 Databases Database size = (#Documents * #Versions) * Avg Size) + (10 KB * (#List items + (#Versions * #Documents))) <<Graphic is removed from a public disclosure point of view>>
    6. 6. Choose the best architecture (for your situation)  Everything “depends” on your situation  1000 concurrent anonymous clients making web-purchases (SSL) VS 10 concurrent clients downloading content (videos / documents) VS 100 concurrent internal users looking for content etc.  Sql is doing nothing and WFE is at 100% VS WFE is sharing it‟s capacity with the SQL proving content CS APP Server is sharing capacity with the SQL index & crawl databases.  All the memory, processors and SSD drives in the world can‟t make up for a bad architecture.
    7. 7. Scaling out for performance  For large, high-performance farms, scale out to multiple SQL Servers  No limit to the number of servers – each database can have its own  Best practice is to break out across some logical boundary (web app, service apps, etc. )  Using clustered SQL servers ?  Consider using instances and make each instance active on a separate physical node
    8. 8. Optimize the DB Server (1)  Request separate drives for:  Log-files  Data-files  TempDB files  Do not run non-SQL apps on SQL Server  Dedicate SQL Server to one SharePoint Farm  If virtualizing  Virtualize WFE and APP servers first  SQL can be virtualized, but it will affect performance (negatively)
    9. 9. Optimize the DB Server (2) + demo  Determine maximum memory  Set fill factor to 80 (only for SP!) + TechNet  Turn on backup compression  Set MAXDOP to 1  Is now mandatory in SP2013  SP Automatic Install AutoSPInstaller Link  Repeatable (Test -> Production)  Customizable (DB Names, Service App Names etc).
    10. 10. Optimize the SQL Instance  Adjust database default locations  Never place on C: drive  Log and data on separate LUNs/physical disks  Test the disks you get offered !  Configure antivirus software to skip LDF/MDF/NDF files  Adjust server memory settings if running multiple instances  Use 64KB allocation units when formatting data and log partitions  You can still do this now! , but it involves some downtime (Up to 50% io performance gains measured !!) Many more!
    11. 11. Optimizing tempdb + DEMO  Pre-size – set to 25% of largest DB  Use simple recovery model  Use AutoGrow of ~ 100MB – if growing, increase initial size  DB Files  Each file on separate LUN, if possible  Store log on its own LUN  Use RAID 1+0 or Raid 10 (local drives)  TechNet SQL Server best practices (2007..) Technet: Best practices for SQL in SP (2013..) Ref
    12. 12. When working with a SharePoint DB  Do not do any of following  Do not add, change or remove any built-in objects (tables, views, stored procedures, triggers, indexes)  Do not directly select from tables or views  Do not change the database collation  Some 3rd party apps will do this automatically ! Hence: keep SharePoint DB just for SharePoint
    13. 13. Optimizing content DBs  Very active content DBs should be placed on their own LUNs  Use RAID 5 or RAID 1+0  In most cases, keep size <200 GB  Why ? Recovering and performance reasons  Use site collection quotas  Don‟t forget about the 2nd stage recycle bin  Use PowerShell to create site collections in their own specific content DB (separation of content)
    14. 14. Why are larger DBs slower ?  Read queries take longer  More rows to filter, group and sort  Write queries take longer  Increased lock contention  Causes more blocking  More data, but data cache same size  DB maintenance takes longer  Reindex  Dbcc checkdb
    15. 15. Achieving storage performance  Storage array (RAID 1+0)  10x 300 GB SAS drives, 15k RPM  1.5 TB effective space  ~1500 IOPS = 1.0 IOPS/GB  Set of drives (RAID 1+0)  4x 750 GB SATA drives, 10k RPM  1.5 TB effective space  ~300 IOPS = 0.2 IOPS/GB
    16. 16. Achieving storage performance (SSD)  Set of drives (RAID 5)  4x 480 GB Intel 520 SSD drives  1.44 TB effective space  ~133.000 IOPS = 92.36 IOPS/GB  IOPS Are A Scam (Brent Ozar)  Use SQLIO and compare the advertised numbers with real world numbers. When the sysadmin brags about SSD RAID 0 speed
    17. 17. Optimizing Search DBs  Max of 25 million items per each crawl and property DB  Store crawl and property DBs on separate, dedicated LUNs  Add data files to match Content DBs  Use RAID 1+0 storage
    18. 18. Agenda  Who am I  Setting up SharePoint, performance gains  Preventing future performance issues  Optimize your current deployment  Trouble-Shooting SharePoint Performance issues  When do you have an issue ?  How to solve the issue ? (Methodology)  Case: Extremely slow uploads on extranet
    19. 19. Reindexing DBs  Fragmentation happens by design – primary key uses GUID columns  Indexes are rebuilt daily as part of health analyzer job*  No manual reindex needed  Do not drop and recreate indexes  Do not alter “auto create statistics” settings (!)  * Make sure you run SharePoint on the latest CU, there are issues with the SharePoint jobs in old releases.
    20. 20. RBS Guidance (Remote BLOB Storage)  Consider using in document-heavy databases  Trade off  Storage costs & performance benefits versus  More complex architecture (support, DR, HA)  Consider third party providers  More full-featured solutions  In general  Do not externalize documents < 1MB  Ideal number varies widely When I fail over to the DR site for the first time
    21. 21. Best Practices  Use SQL Enterprise edition for best performance  Backup logs regularly to prevent runaway log files  Do not use autoshrink  Shrink manually only when needed  Do not use multiple file groups  Not supported by SharePoint  Run database integrity checks ! (DBCC CheckDB)  Use Instant File Initialization  Database Maintenance For SharePoint Tips + Technet article
    22. 22. Agenda  Who am I  Setting up SharePoint, performance gains  Preventing future performance issues  Optimize your current deployment  Trouble-Shooting SharePoint Performance issues  When do you have an issue ?  How to solve the issue ? (Methodology)  Case: Extremely slow uploads on extranet
    23. 23. Top reasons for a Slow SharePoint (1)  The recovery model for the content database is set to full by default. (SQL)  Search indexing, if it kicks in, consumes resources that you might need on your WFEs and SQL Servers for processing of requests. (SQL + WFE / APP)  Anti-virus software, if it is scanning every document that is uploaded, or is scanning the database or BLOB storage directly, it can slow things down tremendously. (APP+OS)  BLOB storage can affect performance – for better or worse. (SQL + Storage)  Database growth sizing (SQL) ref
    24. 24. Top reasons for a Slow SharePoint (2)  The WFE can be a bottleneck (wrong load-balance settings SP farm) (WFE)  Connection between WFE & SQL (Network)  An avalanche of large media (Videos, PowerPoints, ZIP files)  Old and unused files hogging valuable SQL Server storage  Lack of scalability ref
    25. 25. Trouble Shooting Performance Issues  Method of trouble shooting  Shotgun methodology  Happy clicking – no purpose without any specific order  Doing the first thing your search engine tells you to do (in production, without understanding)  Throwing the toolbox at the problem – trying everything whether or not it makes sense  If lucky, you find a solution you can‟t explain, reproduce or understand When I troubleshoot with the shotgun methodology and it backfires (HT @Mike_Walsh)
    26. 26. Trouble Shooting Performance Issues  Method of trouble shooting  Using a trouble shooting pattern (borrowed from ER) - Gather initial information - Prepare your mind - Work as a team - Plan your attack - Don‟t be afraid of asking for help - Formulate a problem statement and verify it with all parties! - Remain calm - Understand priority and if the issue is stable or declining - Anticipate changes and plan ahead for worsening - Use all of the information available - Documentation - Clean up and preparation for next call
    27. 27. Trouble Shooting Be Careful!  Always be cautious in live / production environments  Try to re-produce the issue in test environment  You might be in for a bit more than just a „performance‟ issue  Things might blow-up very quickly !
    28. 28. Case: Triage SharePoint Performance Issue = ~ 30 Minutes…
    29. 29. Case: Triage SharePoint Performance Issue  Looking at the indicators  Using the toolbox to see what‟s going on.
    30. 30. Case: Triage SharePoint Performance Issue  Install Sp_AskBrent
    31. 31. Case: Triage SharePoint Performance Issue
    32. 32. Thank You ! Don’t Do it! Optimizing SQL 2008 for SP SharePoint Performance TroubleShooting When the Microsoft sales rep hears me questioning whether anybody’s really on Azure