WHITE PAPER Improve Business Productivity and User Experience with a SanDisk Powered SQL Server 2014 In-Memory OLTP Database 951 SanDisk Drive, Milpitas, CA 95035 www.sandisk.com
Table of Contents Executive Summary... 3 Introduction: In-Memory Meets Fusion iomemory... 4 What Is In-Memory OLTP?... 4 Unleash SQL Server 2014 In-Memory OLTP Database From I/O Constraints...5 Eliminate Continuous Checkpoint Slowdowns...5 Improve HA and Maintenance by Accelerating Reboots, Restarts, and Failovers...5 About the Tests... 6 Server Configuration... 6 Storage Configuration... 6 Operating System Configuration...7 SQL Server 2014 Configuration: Dell PowerEdge R720...7 Workload Configuration...7 Test Results... 8 40GB In-Memory OLTP Transactional Workload Test Results...8 Overall Performance...8 Memory-Optimized Filegroup Performance... 9 Transaction Log Performance...10 Database Startup Tests... 12 Database Startup Performance... 12 Scaling Beyond 12,000 Users... 13 Summary...14 : Is SQL Server In-Memory OLTP Right for You?...15 Table Usage Analysis... 25 Table Contention Analysis... 27 Stored Procedure Usage Analysis... 28 Memory Optimization Advisor...29 Native Compilation Advisor...36 2
Executive Summary There has been a lot of press recently about in-memory databases, and with good reason: business user requests served from memory are lightning-fast. An in-memory database can easily process an order of magnitude more transactions per day, and is therefore capable of order of magnitude greater business productivity. SQL Server In- Memory OLTP allows specific key tables to be memory-optimized while maintaining the investment in the T-SQL code base. SQL Server In-Memory OLTP shows dramatic performance increases in a typical system and allows business users to choose which business objects should be placed in memory, based on critical need. This paper shows how combining Fusion iomemory products with SQL Server In-Memory OLTP improves the customer experience even more. It does this by improving system response time and business productivity (transactional processing capabilities), allowing more customers to be served per server, all the while dramatically reducing costs compared to traditional storage solutions. The following table summarizes results of performance testing performed by SanDisk on a Dell PowerEdge R720 and validated by Microsoft. Business Value Key Performance Indicators Enterprise-Class Disk Array with 2014 SQL Server In-Memory OLTP iodrive 2 Duo 2.4TB with SQL Server 2014 In-Memory OLTP Business Process Improvement Improve Customer Experience User Transaction Wait Time (µ) 1329 117 Reduced user wait times by 91% Serve More Customers Transaction Throughput (MB/s) 42 172 Increased throughput by 409% Improve Business Productivity Total Transactions Processed (over 45 minutes) 6,362,883 28,328,639 Processed 445% more transactions Deliver on Internal Service Level Agreements Database Startup Time (sec) 222 72 Reduced startup time by 67% 3
Introduction: In-Memory Meets Fusion iomemory While SQL Server 2014 In-Memory OLTP brings never-before-seen performance levels and capabilities to SQL Server databases, these new capabilities require a storage subsystem that delivers consistent low latency, ultra-high bandwidth, and strong reliability. Backing SQL Server In-Memory OLTP databases with Fusion iomemory products is critical in driving the highest transaction performance levels. This is done with the simplest, most cost-effective approach, compared to legacy storage architecture. What Is In-Memory OLTP? In-Memory OLTP is a memory-optimized database engine for SQL Server 2014. In-Memory OLTP enables transactional database applications to significantly improve transactional throughput by providing contention-free access to tables, by way of native code. Other In-Memory database platform offerings often require re-tooling application code. This could be due to the need for deploying a new data access method, or even having enough RAM to house the entire database. SQL Server 2014 does not require the entire database to be placed into RAM the developer can choose which tables would benefit the most from becoming memory-optimized tables. While there are some restrictions as to data types that may be a part of a memory-optimized table, the base data types are supported. Stored procedures that access the selected memoryoptimized tables may be compiled into native code, which executes faster. The end result is that much of the T-SQL code can be leveraged, taking advantage of new SQL Server In-Memory OLTP paradigms where the most value can be gained. Even when there is enough RAM in the server to hold the entire database in memory, SQL Server s access mechanism still operates on the concept of a page of data. It goes through the process of latching and locking to ensure data consistency. SQL Server In-Memory OLTP has an optimistic approach to concurrency. There is no latching or locking, but there is a mechanism to detect conflict based on row versioning. Also, there is no longer a concept of a page of data within the SQL Server In-Memory data structures. With no pages to latch or lock, there is a significant improvement in performance, as there is no waiting on resource availability and execution is unleashed. 4
Unleash SQL Server 2014 In-Memory OLTP Database From I/O Constraints No matter how powerful the database system, performance will always be limited at some point by chokepoints and bottlenecks. Fusion iomemory products resolve several I/O bottlenecks to raise the bar on capabilities for SQL Server 2014 In- Memory OLTP database. ELIMINATE CONTINUOUS CHECKPOINT SLOWDOWNS To ensure durability, SQL Server In-Memory OLTP relies heavily on the NTFS file system to store data and delta files in a database file group optimized for in-memory data. SQL Server In-Memory OLTP uses an offline checkpoint process to track and manage inserted and deleted data. This generates a considerable amount of sequential disk I/O activity and increases transaction log activity. Write performance is key as transaction log activity is increased. This is due to the highly concurrent, contention-free transactions generated in memory. Fusion iomemory products direct-path architecture provide industry-leading, near-dram write performance, which is often overlooked when discussing flash storage. This architecture enables performance more effectively than SSDs do, because SSDs place traditional storage protocols and RAID controllers between the data and the application, making it much more difficult to deliver consistent write performance. IMPROVE HA AND MAINTENANCE BY ACCELERATING REBOOTS, RESTARTS, AND FAILOVERS In addition to the continuous checkpoint process, SQL Server In-Memory OLTP benefits by reading data in parallel. The parallel read process happens a) when loading data from the data and delta files into memory during a server reboot, b) when restarting the SQL Server service, or c) when setting the database offline. This process generates random I/O and relies on a high-performing disk subsystem to load tables into memory. The closer the data is to the CPU, the faster it will load into memory. As with the continuous checkpoint, Fusion iomemory products direct-path architecture gives the database server CPUs direct access to the data and delta files, which accelerates reboots, restarts, and failover processes. 5
About the Tests Testing compared performance of an iodrive2 Duo 2.4TB card in a Dell PowerEdge R720 server to an enterprise-class disk array in three key areas: 1. Transactional Performance. How the two systems performed under the heavy I/O workload generated by the inmemory transaction log activity and continuous checkpoints. Tests were conducted on latency (responsiveness), and bandwidth (transactional workload) with 12,000 users. 2. Database Startup. As the database is running out of memory on servers, loading the database quickly becomes a key factor in system resilience. We tested how fast the transactional database could be brought online to compare how the two systems would handle a server reboot or cluster failover event. 3. User Load. Tests were limited to 12,000 users because, at that point, the disk array started experiencing timeouts. Additional testing measured the total user load of a Fusion iomemory system to demonstrate an additional aspect of scalability. Server Configuration The following settings were enabled in the BIOS: Logical Processor was enabled. With Hyper-threading enabled, we were able to increase the number of users by 8000 in further testing. System Profile Settings was set to performance. Virtualization was disabled. Fan Offset was set to high. Node Interleaving was disabled. Storage Configuration One iodrive2 Duo 2.4TB card was used as the storage for the in-memory database within the Dell R720 server. The iodrive2 Duo product appears as two physical block devices to the host operating system. One block device was used for the memory-optimized filegroup and disk-based filegroup. The remaining block device was used exclusively for the transaction log. The enterprise class storage array was configured with two storage pools. The first storage pool was comprised of 12 spindles and was used to store the memory-optimized file group, the disk-based data files, and tempdb. The second storage pool was comprised of 12 spindles and was used exclusively for the in-memory database transaction log. 6
Figure 1. Storage layout of enterprise class disk array and Fusion iomemory iodrive2 Duo 2.4TB card. Note: Neither tempdb nor the disk-based tables were accessed during testing. All tables were marked for in-memory use. Operating System Configuration We used the Interrupt-Affinity Policy Tool to bind the iodrive2 card interrupts to CPU0. The Interrupt-Affinity Policy Tool can be found at http://msdn.microsoft.com/en-us/windows/hardware/gg463378. SQL Server 2014 Configuration: Dell PowerEdge R720 Name Baseline Values Fusion iomemory Values Transactional Database data files 1 per core 1 per core Tempdb data files 1 per core 1 per core Max Degree of Parallelism 1 1 Min/Max Server Memory (MB) 256,000 256,000 Lock Pages in Memory Enabled Enabled Workload Configuration A custom benchmark application generated a transactional workload on the systems. The benchmark application was configured with the following parameters. Parameter Duration In-Memory OLTP Database Size Values 45 minutes 30GB Users to generate load 12,000 User Delay (ms) 0 Repeat Delay (ms) 0 Minutes of Ramp Time 0 7
Test Results This section shows the test results by each category of test: transactional workload performance and database start-up performance. The transactional workload performance results are shown by category: overall performance, memoryoptimized filegroup performance, and transaction log performance. The charts reflect testing with a scale of 12,000 users because the storage array s capabilities peaked at that workload. Testing beyond a 12,000 user load resulted in timeouts with In-Memory OLTP, which stopped data processing for extended periods of time. 40GB In-Memory OLTP Transactional Workload Test Results OVERALL PERFORMANCE The chart below shows a summarized view of the transactional performance testing results. Across all performance indicators, Fusion iomemory technology increases business productivity by providing more transactional throughput with significantly lower latency. Figure 2. Fusion iomemory products increase In-Memory OLTP performance more effectively than an enterprise disk 8
MEMORY-OPTIMIZED FILEGROUP PERFORMANCE One set of tests compared write bandwidth and latency of Fusion iomemory products to an enterprise disk array to see how each handled the impact of background processes, such as continuous checkpoint. As the charts show, the Fusion iomemory system delivers consistent high performance, which helps ensure durability. Figure 3. Fusion iomemory products enable 84% faster in-memory checkpoint processes with much less variation. Figure 4. Continuous checkpoints are faster due to 75% higher average bandwidth. 9
TRANSACTION LOG PERFORMANCE The in-memory database results in much greater workload on transaction logs. Slow I/O on the transaction log reduces database performance. Tests measured the average and maximum transactions per second that the two systems completed over a 45-minute period. Tests also measured latency to compare transactional processing speeds to show the responsiveness of the database under load, and the speed it can serve individual requests. Fusion iomemory products completed 4.5x more transactions over the test period, and did so with much higher response times, thus making each database server more scalable. Figure 5. Fusion iomemory system enables 4.4X more user transactions per second. Figure 6. 76% faster continuous checkpoint performance increases transactional processing speeds and business productivity. 10
Figure 7. 91% lower latency delivers consistently fast response times, which improves the user experience and helps IT confidently meet SLAs. Figure 8. 4X faster transaction log writes eliminates I/O slowdowns. 11
Database Startup Tests DATABASE STARTUP PERFORMANCE The database startup test measured how long it took to load 120GB of data into DRAM. As the chart below shows, the data loaded in 72 seconds from the iodrive2 Duo, as opposed to 222 seconds from the disk array or 308% faster. This performance increases system resilience and facilitates maintenance, enabling organizations to deliver on internal Service Level Agreements (SLAs). Figure 9. Database startup on Fusion iomemory is 308% faster than from an enterprise disk array. 12
Scaling Beyond 12,000 Users In addition to testing transaction processing scalability, it s useful to know the user load each server can support. Accordingly, testing was extended beyond 12,000 users. As stated above, our storage array testing peaked at 12,000 users due to severe write latency. With the Fusion iomemory solution, our scalability test peaked at 24,000 users before processor utilization reached 80%. Figure 10. With 24,000 users write latency consistently stays under 220 microseconds. 13
Figure 11. Database transactions average 109,000 per second once all 24,000 users are on the system. Summary Fusion iomemory products extend the power of SQL Server 2014 In-Memory OLTP databases by removing I/O bottlenecks associated with transaction logs and checkpoints that become more severe under the workload of an inmemory database. They also increase startup, reboot, and failover speeds to increase resiliency. Finally, they also increase the user load each server can support. The table below summarizes the benefits. Business Value Key Performance Indicators Enterprise-Class Disk Array with 2014 SQL Server In-Memory OLTP iodrive 2 Duo 2.4TB with SQL Server 2014 In-Memory OLTP Business Process Improvement Improve Customer Experience User Transaction Wait Time (µ) 1329 117 Reduced user wait times by 91% Serve More Customers Transaction Throughput (MB/s) 42 172 Increased throughput by 409% Improve Business Productivity Total Transactions Processed (over 45 minutes) 6,362,883 28,328,639 Processed 445% more transactions Deliver on Internal Service Level Agreements Database Startup Time (sec) 222 72 Reduced startup time by 67% 14
: Is SQL Server In-Memory OLTP Right for You? On the surface, workloads that are characterized by a high amount of latching or locking would be classified as good candidates for the SQL Server 2014 In-Memory OLTP feature. While that may be true, Microsoft SQL Server 2014 provides several advisor tools and usage reports to help identify which tables and stored procedures are the best candidates for storing in memory. It is highly recommended that you a) configure the Management Data Warehouse to collect usage analysis on tables and stored procedures; and b) run the advisory tool to determine which tables and stored procedures would benefit from In-Memory OLTP. As mentioned previously, a full database migration isn t required. Database administrators have the flexibility to move individual tables and stored procedures into SQL Server In-Memory OLTP. More information on In-Memory OLTP migration can be found here: http://msdn.microsoft.com/en-us/library/dn247639(v=sql.120).aspx Below is the step-by-step procedure to analyze and migrate data: 1. Configure the Management Data Warehouse (Data Collection > Tasks > Configure Management Data Warehouse). 15
2. Click Next to progress through the wizard. 16
3. Create your Management Data Warehouse (MDW) database. 17
4. Select the appropriate server and newly created MDW database. 18
5. Add necessary logins and users. 19
6. Verify actions and click Finish. 20
7. Click Close. 21
8. Select the appropriate server and database. Check the box for Transaction Performance Collection Analysis. 22
9. Click Finish. 23
10. In Object Explorer navigate to Data Collection, right click Stored Procedure Usage Analysis and select Start. Then right click Table Usage Analysis and select Start. 24
11. Right click the MDW database. Select Reports > Management Data Warehouse > Transaction Performance Analysis Overview. The AMR tool for In-Memory OLTP opens. Table Usage Analysis In the AMR tool for In-Memory OLTP you can view analysis on tables, stored procedure usage, and table contention. 25
The Table Usage chart illustrates which tables would benefit from SQL Server In-Memory OLTP, based on usage. The chart also illustrates the degree of migration difficulty. 26
TABLE CONTENTION ANALYSIS The Table Contention chart illustrates which tables would benefit from In-Memory OLTP, based on table contention. The chart also illustrates the degree of migration difficulty. 27
STORED PROCEDURE USAGE ANALYSIS The Stored Procedure report uses a bar chart to identify which procedures will be benefit from In-Memory OLTP based on usage, with CPU time measured in milliseconds. 28
MEMORY OPTIMIZATION ADVISOR Before starting a table migration to In-Memory OLTP, we recommend reading the migration information on Microsoft TechNet at http://technet.microsoft.com/en-us/library/dn247639(v=sql.120).aspx. Below is a step-by-step procedure for migrating tables: 1. This advisor is based on the recommendations from the AMR reports. Right click the table to migrate and select Memory Optimizer Advisor. 29
2. Follow the screens in the wizard. 30
3. If necessary, fix the items that failed during the Memory Optimization Checklist step. Click Next. 31
4. Fix all warnings to ensure a smooth migration. 32
5. Name the memory-optimized file group, change the logical file name if necessary, and change the table name. 33
6. Select the appropriate primary key column(s) and hash bucket size for the non-clustered index. Click Next. 34
7. Complete the migration. 35
Native Compilation Advisor Below is a step-by-step procedure for using the Native Compilation Advisor: 1. Click Next. 36
2. Fix the code in the stored procedure associated with the warnings listed in the dialog. 37
3. Develop workarounds for unsupported TSQL elements. FOR MORE INFORMATION Contact a SanDisk representative, 1-800-578-6007 or fusion-sales@sandisk.com The performance results discussed herein are based on testing and use of the above discussed products. Results and performance may vary according to configurations and systems, including drive capacity, system architecture and applications. 2014 SanDisk Corporation. All rights reserved. SanDisk is a trademark of SanDisk Corporation, registered in the United States and other countries. Fusion iomemory, iodrive, and others are trademarks of SanDisk Enterprise IP LLC. Other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). 38