SharePoint Performance

cis
October 2013
Jeroen
Schoenmakers
N E W H O R I Z O N S
SharePoint Performance

Who am I ?
 Jeroen Schoenmakers aka
 @Shuwi
 Linked in
 15 years SQL DBA & .NET Dev experience
 5 Years SharePoint experience
 MCITP,MCTS
 http://Schoennie.BlogSpot.com

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

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.

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>>

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.

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

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)

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).

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!

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

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

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)

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

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
 ~300 IOPS = 0.2 IOPS/GB

Achieving storage performance (SSD)
 Set of drives (RAID 5)
 4x 480 GB Intel 520 SSD drives
 ~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

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

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

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.

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

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

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

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

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)

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

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 !

Case: Triage SharePoint Performance Issue
= ~ 30 Minutes…

 Looking at the indicators
 Using the toolbox to see what‟s going on.

 Install Sp_AskBrent

Thank You !
Don’t
Do it!
http://Schoennie.blogspot.com
Optimizing SQL 2008 for SP
SharePoint Performance TroubleShooting
http://dbareactions.tumblr.com/
When the Microsoft sales rep hears me
questioning whether anybody’s really on
Azure

SharePoint Performance

Recommended

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to SharePoint Performance (20)

Recently uploaded (20)

SharePoint Performance

Editor's Notes