I attended a suguk.org event in London about a week ago. John Timney did the 1st presentation session and asked a couple of questions on SharePoint limits. I didn't know the answers, tried to think back to MOSS and what I'd seen previously. The simplest question that I should know the answer to:
Qu: What is the maximum content database size supported by SharePoint 2010?
Ans: Microsoft supports Content databases up to 200GB in size. In MOSS it was 100GB. It is fairly common to see content databases considerably bigger than 100GB in MOSS that work. The issue is how long does it take to perform operations on these content DB's such as backups moving content db's. If you have a dedicated SAN, there is no reason not to go to much larger content databases however, they are not supported by MS.
More info on SharePoint's boundaries and thresholds from MS
Qu: What I/O speed does MS recommend for your SharePoint 2010 SQL database?
Ans: I/O operations per second (IOPS). The faster that SQL can handle request, results in faster return time and reduced que requests, so pretty important and a fairly common bottleneck. This is often a reason why people choose not to virtualise SQL Server, it I/O intensive in SharePoint and really important to be fast. Tip: Ensure VM's are thick provisioned for SQL Server.
To determine you IOPS use SQLIO Disk Subsystem Benchmark Tool (http://go.microsoft.com/fwlink/?LinkID=105586).
I guest the answer is as fast as possible but you can determine your IOPS requirement using the tool and you usage. I go with ldf files on the fastest disk on the TempDB followed by ldf files for the content dbs on spinning disks.
Update 09/06/2011
Qu: Should I using seperate disks for mdf (data files) & ldf (transaction logs)?
Qu: What is the default SQL Server database growth setting sizes?
Ans: SQL Server 2008 will grow data files by 1MB and transaction logs by 10% increments. I would start with an initial content database size of 100MB(adjust according to your anticipated demand) and autogrowth to be 50MB (adjust according to your system). This general prinipal will result in the growth to the db's being infrequent so the associated performance hit is reduced, unused space being optimised as the percentage growth in the transaction log has huge incremental hit that are generally never reached after initial growth and less fragmented databases results in faster performance.
More Info:
Summary of limits and thresholds
http://blah.winsmarts.com/2010-5-How_big_can_my_SharePoint_2010_installation_be.aspx
SQL Checklist for SharePoint 2013
Qu: What is the maximum content database size supported by SharePoint 2010?
Ans: Microsoft supports Content databases up to 200GB in size. In MOSS it was 100GB. It is fairly common to see content databases considerably bigger than 100GB in MOSS that work. The issue is how long does it take to perform operations on these content DB's such as backups moving content db's. If you have a dedicated SAN, there is no reason not to go to much larger content databases however, they are not supported by MS.
More info on SharePoint's boundaries and thresholds from MS
Qu: What I/O speed does MS recommend for your SharePoint 2010 SQL database?
Ans: I/O operations per second (IOPS). The faster that SQL can handle request, results in faster return time and reduced que requests, so pretty important and a fairly common bottleneck. This is often a reason why people choose not to virtualise SQL Server, it I/O intensive in SharePoint and really important to be fast. Tip: Ensure VM's are thick provisioned for SQL Server.
To determine you IOPS use SQLIO Disk Subsystem Benchmark Tool (http://go.microsoft.com/fwlink/?LinkID=105586).
I guest the answer is as fast as possible but you can determine your IOPS requirement using the tool and you usage. I go with ldf files on the fastest disk on the TempDB followed by ldf files for the content dbs on spinning disks.
Update 09/06/2011
Qu: Should I using seperate disks for mdf (data files) & ldf (transaction logs)?
Ans: On small SQL server farms ensure that the transaction logs are stored on a different physical drive to the content databases as this will reduce contention and increate performance signigicantly. Larger SQL instances like SANS have multiple disks so there is no need to seperate the files as this is already done by the nuber of disk readers. You can also check the performance of a drive by watching the "disk seconds per read/write counters" which should be less than 20ms. If the disk seconde per read/write is approachiing 20ms consider improving the disk speed or increasing the number of read points.
Update 22/08/2012 - Bigger architectures may use SSD/Flash memory as opposed to disks. The IOPS are hugely improve as the is no disk search time. http://technet.microsoft.com/en-us/library/cc298801.aspx#Section1_5a
Update 22/08/2012 - Bigger architectures may use SSD/Flash memory as opposed to disks. The IOPS are hugely improve as the is no disk search time. http://technet.microsoft.com/en-us/library/cc298801.aspx#Section1_5a
Qu: What is the default SQL Server database growth setting sizes?
Ans: SQL Server 2008 will grow data files by 1MB and transaction logs by 10% increments. I would start with an initial content database size of 100MB(adjust according to your anticipated demand) and autogrowth to be 50MB (adjust according to your system). This general prinipal will result in the growth to the db's being infrequent so the associated performance hit is reduced, unused space being optimised as the percentage growth in the transaction log has huge incremental hit that are generally never reached after initial growth and less fragmented databases results in faster performance.
More Info:
Summary of limits and thresholds
http://blah.winsmarts.com/2010-5-How_big_can_my_SharePoint_2010_installation_be.aspx
SQL Checklist for SharePoint 2013
0 comments:
Post a Comment