Continuous resource monitoring for self-predicting DBMS Dushyanth Narayanan 1 Eno Thereska 2 Anastassia Ailamaki 2 1 Microsoft Research-Cambridge, 2 Carnegie Mellon University Umar Farooq Minhas 08 Nov 2006 David R. Cheriton School of Computer Science University of Waterloo

2 Outline  Problem: DBMS Administration  Solution: Resource Advisor  Resource Advisor Architecture  Experiments  Summary  Past Present & Future  Discussion/Q&A

3 Problem: DBMS Administration  Complex & expensive  Key Task: Resource provisioning Vital to ensure QoS Current Techniques  Rules of thumb  Concurrent OLTP loads (a nightmare)  Result: Over-provisioned DBMS Wasteful Prohibitively expensive Tuning still a management issue  Solution: Self-predicting DBMS

4 Solution: Resource Advisor (RA)  Goals: Get quantitative answers to “what-if” questions from DBMS  Point predictions  “how will response time change if memory is doubled?”  Trend forecasting  “what is the shape of memory vs. response-time curve?” Provide visualization of system performance

5 RA Architecture

6 RA Resource Monitoring  DBMS instrumentation Insert check-points that  Generate events e.g. StartRequest, EndRequest, SuspendTask, BufferGet, DiskIOComplete, …, etc.  Helps track CPU, Memory and I/O resource usage  Demand trace extraction Hardware-independent workload demand trace Associate each event to its transaction Group transactions by type e.g. “new_order”

7 RA Visualization

8 RA Architecture

9 Buffer pool model  Input: Reference trace Buffer pool size  Predicts: # of blocking & non-blocking I/Os as a function of buffer pool size  Implementation: DB Cache simulator  Globally shared buffer cache  Least Frequently Used (LFU) eviction policy

10 Storage model  Input: Storage parameters  #of cylinders, seek time,…,queue size etc # of I/O requests (buffer pool model)  Predicts: I/O service time as a function of storage parameters  Implementation: Analytical model  Shortest Seek Time First (SSTF) scheduling  Assumes a random I/O request stream

11 Throughput prediction  Identify the bottleneck resource as one of CPU, memory, I/O or client  System throughput = bottleneck resource throughput  T = Min { T max/io, T max/CPU, T max/workload } n io, t io predicted by buffer pool & storage model respectively T open for open loop inversely proportional to CPU speed specified by DBA

12 Response-time prediction  Response time depends on critical path  critical path = time spend on cpu + disk t response = t CPU + t storage t CPU is measured t storage depends on number of blocking I/Os per transaction and service time per I/O predicted by buffer pool model predicted by storage model

13 Experimental Setup  2 variants of TPC-C workload (open,closed)  10 GB MS SQL Server Database on Intel Xeon 2.7 GHz Processor  200 clients concurrently accessing DB  64, 128, 256, 512, 1024 MB buffer size  CPU and disks unchanged

14 Experiments  Closed-loop throughput prediction  Saturation throughput prediction  Open-loop response time prediction  Resource advisor overheads Higher at lower buffer pool sizes Worse case CPU overhead 6.2% (online)  Reduces to 1.2% for offline 189 additional LOC required in SQL Server RA itself: 1150 LOC

15 Summary  Problem: How to over-come current issues and challenges in DB Administration (particular to resource provisioning)?  Solution: DBMS should be self-predicting  Implementation: Resource Advisor to enable self-prediction in DBMS Experimental evaluation

16 RA Past Present & Future  “Towards self-predicting systems: What if you could ask “what-if”?” DEXA (August 2005)  “Continuous resource monitoring for self-predicting DBMS” MASCOTS (Sept 2005)  “Informed data distribution selection in a self-predicting storage system” January 2006  “Stardust: Tracking Activity in a Distributed Storage System” SIGMETRICS/Performance ACM (June 2006)

17 Discussion / Q&A  The storage model & throughput prediction have recursive dependency for calculating response time t io and throughput T, the underlying assumption is that (T, t io ) values will converge, what happens if they don’t ?  The number of I/Os are predicted by the buffer pool model by using a DB Cache Simulator, what effect would a different kind of simulator have with the overall performance of RA? How to choose?  RA has been specifically shown to work on TPC-C benchmark under some assumptions, can we really expect to get comparable results in general for other OLTP workloads? Is RA usable at all with other workloads?