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 DatabasesDatabase 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) VS10 concurrent clients downloading content (videos / documents) VS100 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 CSAPP 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

SQL Server: The Most Important Factors

1) RAM

See my blog post :"How to prove your sql server needs more memory”

2) CPU

3) Storage

SSD & SAN are best performance (greatest IOPS)

Work with your storage vendor when configuring Logical Unit Numbers (LUNs)

4) Network

When the client asks how much it would cost to add 1GB of ram to the database server. (HT @RandomNoun7)1

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

1.5 TB effective space

~300 IOPS = 0.2 IOPS/GB

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

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

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

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…

Case: Triage SharePoint Performance Issue

Looking at the indicators

Using the toolbox to see what’s going on.

Case: Triage SharePoint Performance Issue

Install Sp_AskBrent

Case: Triage SharePoint Performance Issue

Thank You !

Don’t Do it!

http://Schoennie.blogspot.comOptimizing SQL 2008 for SPSharePoint Performance TroubleShootinghttp://dbareactions.tumblr.com/

When the Microsoft sales rep hears me questioning whether anybody’s really on Azure