Hardware planning & sizing for sql server

18,889 views

Published on

Purchasing a dedicated server to SQL Server is still a necessary operation. The cloud is a great choice but if you need to create a data warehouse of non-trivial size or if you have the need for optimal performance and control of your production database server, the choice of on-premise server is still an optimal choice. So, how not to throw away money on unnecessary hardware? In this session we will see how each component works together to form a balanced hardware (this is the key word!), without bottlenecks, maximizing the investment made. We'll talk about SAN, CPU, HBA, Fibre Channel, Memory and everything you thought you knew well...

Published in: Technology
2 Comments
17 Likes
Statistics
Notes
No Downloads
Views
Total views
18,889
On SlideShare
0
From Embeds
0
Number of Embeds
151
Actions
Shares
0
Downloads
654
Comments
2
Likes
17
Embeds 0
No embeds

No notes for slide
  • All images usedeare © of respectiveauthors
  • http://en.wikipedia.org/wiki/PCI-X
  • http://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay/?sp4ts.oid=254869&spf_p.tpst=kbDocDisplay&spf_p.prp_kbDocDisplay=wsrp-navigationalState%3DdocId%253Demr_na-c01647212-2%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetokenhttp://en.wikipedia.org/wiki/PCI_Express
  • Hardware planning & sizing for sql server

    1. 1. Hardware Planning & Sizing for SQL Server Davide Mauri dmauri@solidq.com
    2. 2. Sponsor & Media Partners
    3. 3. Davide Mauri  18 Years of experience on the SQL Server Platform  Specialized in Data Solution Architecture, Database Design, Performance Tuning, Business Intelligence  Projects, Consulting, Mentoring & Training     Regular Speaker @ SQL Server events Microsoft SQL Server MVP President of UGISS (Italian SQL Server UG) Mentor @ SolidQ
    4. 4. Requirements What’s the typical RDBMS requirement? Performance!
    5. 5. Expectations So you would expect an OLTP server to be like a… F1 Car!
    6. 6. Expectations Or, if you’re into Business Intelligence, you would expect a great (Fast) Truck!
    7. 7. Reality Let’s do a reality check. Typical servers are… …Something Else…
    8. 8. Why this happens? Huge misunderstanding on hardware features… «System is slow, we need an upgrade to improve performance» «Here’s 2 TB of more space» «WTF!?!?!?»
    9. 9. Balanced Systems The only way to go is to have balanced systems Balanced: pay and use everything no single bottleneck nothing more than what you can consume
    10. 10. Just wasting money Unbalanced system is just a money black hole Wasted money on Licenses Hardware HW/Storage Consultants DBA SYS Admins Developers
    11. 11. Performance Pillars Database Design • Logical • Physical Server Index Query Hardware • Configuration • Maintenance • Definition • Maintenance • Evolution • Good T-SQL • Tuning • No bottlenecks
    12. 12. The (simplified) I/O full stack SQL Server Windows CPU Memory I/O Controller Disk Array Performance
    13. 13. Is that a good system? 40 Cores (80 with HT) 128 GB RAM SAN with 2 TB of disk space ?
    14. 14. Answer My feeling? Not really. Some important data is missing. How many disks? How the SAN is connected to the server?
    15. 15. How to evaluate & balance a server No easy way…but! How do you evaluate a car? Put it on a standard test track Measure peak performance Measure peak resource consumption Declare results Compare results
    16. 16. How to evaluate & balance a server Of course you’ll never get the declared values in real-life usage Still they are a good way to Understand if that car is good for your Compare it against other cars
    17. 17. Use published data Let’s do some math with published or wellknown values TPC Benchmarks Let’s start to evaluate a Data Warehouse since is much more simpler than a OLTP system
    18. 18. CPU A minimum of 300MB/s of Maximum Consumption Rate per core For today’s CPUs A four core processor is able to consume 1.2GB/sec of raw data Is your system able to give that throughput?
    19. 19. Memory Memory usually has a very high bandwidth A DDR3 Memory Pair can provide 10GB/Sec No problems here 
    20. 20. PCI-X o PCIe BUS PCI-X v1 X4 slot: 750 MB/sec PCI-X v2 X4 slot: 1.5 – 1.8GB/sec
    21. 21. PCI-X o PCIe BUS PCIe (per lane) v1.x: 250 MB/s v2.x: 500 MB/s v3.0: 985 MB/s v4.0: 1969 MB/s PCIe v2.0 x16 8 GB/sec
    22. 22. Storage: Spindles A «classic» HDD (a «spindle») the following numbers: Sequential IO 90MB/sec to 125MB/sec for a single drive Random IO usually much lower SQL Server tries to convert rnd to seq
    23. 23. Storage: Interconnection How are your drives connected to the server? DAS: Direct Attached Storage SAN: Storage Area Network
    24. 24. Storage: DAS Standards: (SCSI), SAS, SATA Typically Integrated controller on the server PCI Direct Access Host-Bus Adapter (HBA) may or may be used
    25. 25. Storage: SAN Host-Bus Adapter (HBA) FC Switch Cache Storage Processor
    26. 26. Storage: SAN – The Numbers 4Gbit FC = 400MB/sec 8Gbit FC = 800MB/Sec PCI-x4 or faster needed! (Anyway PCIe is becoming the standard)
    27. 27. Building the server  4 x 8-Core CPU  4 * 8 * 300 MB/Sec = 9600 Mb/Sec = ~10Gb/Sec  12 x 8Gbit FC HBA  12 * 800 MB/Sec = 9600Mb/Sec = ~10Gb/Sec  64 x 15K RPM Discs  64 * 150MB/Sec = 9600 Mb/Sec = ~10Gb/Sec
    28. 28. Building the server  SAN & PCIe Slots  # Vary depending on model  Eg: SAN supports 16Gbit:  6 SAN  12 PCIe 8x  RAM  As much as you can 
    29. 29. Database File Placing LUN 1 DataFile1.ndf LUN 2 DataFile2.ndf LUN 3 DataFile3.ndf LUN 4 DataFile4.ndf LUN «n» DataFileN.ndf SAN 1 FILEGROUP SAN 2 SAN «n»
    30. 30. Was it all worth it?
    31. 31. Performance Baselining: Storage SQLIO Free tool to measure IO from Microsoft IOMeter Free, open source, tool
    32. 32. Performance Baselining: System Use TPC Databases and tools to measure performance and compare different systems www.tpc.org OLTP TPC-C & TPC-E DW/BI/DSS TPC-H & TPC-DS
    33. 33. Is that all?  It’s ALL about hardware!  Just keep in mind that it’s only a part of the game  Remember to measure latency (continuously!)  Use SQL Server DMVS to monitor Wait Stats  Use H/W monitoring tools
    34. 34. OLTP Workload Type Notes Mainly random read / writes Depending how much “pure” OLTP is Read-Head are sequential Optimize for Random I/O Spindle count IOPS & Latency is the key measure
    35. 35. DW Workload Type Notes 64-512KB reads table and range scan 128-256KB writes bulk load Optimize for high aggregate throughput I/O MB/Sec is the value to monitor
    36. 36. SSAS Workload Type Notes Up to 64KB random reads, (Avg. 32KB) Highly random and often fragmented data Optimize for Random, 32KB blocks IOPS & Latency is the key measure
    37. 37. Fast Track Data Warehouse Reference architecture Guide to create a balanced system optimized for DW workload Large Scans of Data IBM, HP & DELL provides hardware
    38. 38. Parallel Data Warehouse  Massively Parallel Processing (MPP) Architecture  Basically several Fast Track all together   Query is split and executed across all nodes
    39. 39. Parallel Data Warehouse
    40. 40. OLTP Appliance  Unfortunately missing in action…  Generalization much more complex than DWH  HP, IBM & DELL have specific whitepapers
    41. 41. OLTP Appliance  Microsoft® SQL Server® 2012 OLTP Workload Benefits Using IBM® XIV® Storage System Gen3 SSD Cache  Achieving a High Performance OLTP Database using SQL Server® and Dell™ PowerEdge™ R720 with Internal PCIe SSD Storage
    42. 42. OLTP Appliance  HP Reference Architecture for High Performance SQL Server
    43. 43. THANKS!

    ×