Goal-Oriented Buffer Management Revisited Kurt P. Brown, Michael J. Carey, Miron Livny Presented by Mike Nie

Agenda  Goal-Oriented Basics  Criteria for Success  Previous Approaches  Class Fencing  Experiments and Results  Conclusion and Discussion

Goal-Oriented Basics  This paper focus on the control of response time of a specific workload.  Knob: Disk buffer memory allocation. K Target DBMS response time goal observed response time memory allocation adjustment

Goal-Oriented Memory Allocation  Definition: “ For each class with an average response time goal, a memory allocation must be found such that its observed response time is as close as possible to its goal. ”  How it works? More buffer memory -> high hit rate High hit rate -> low response time

Criteria for Success - I  Accuracy Observed average response time should be close to its goal.  Responsiveness The number of knob adjustment to the goal should be minimum.  Stability The variance of observed average response time should be small.

Criteria for Success - II  Overhead The controller should minimize the resource it consumes.  Robustness The system should handle a wide range of workloads.  Practicality Make fair assumptions about workload and DBMS in general.

Goal-Oriented Buffer Allocation Manager Architecture  Response time estimator Fn: hit rate -> est. response time  Hit rate estimator Fn: memory allocation -> est. hit rate  Buffer allocation mechanism A mechanism to divide up memory between workloads.  Inverse the functions to calculate buffer allocation plan. Goal res. Time -> hit rate -> memory allocation

Dynamic Tuning  Response time estimator: R est = (1.0-HIT est (M)) * D  Hit rate estimator: HIT est =1 - a/M b  Buffer allocation mechanism: Partation buffer pool based M calculated above for each class.

Dynamic Tuning Issues  Overshoot  Low responsiveness  No shared data between workloads

Fragment Fencing - I  Response time estimator: Response time and buffer miss rate are directly proportional.  Hit rate estimator: HIT target = 1.0-(M obsv *(R goal /R obsv ))  Goal: determine the minimum number of pages that must be in memory to achieve an overall target hit rate for the class.

Fragment Fencing - II  Buffer allocation mechanism Passive allocation  Issues: Having trouble when fragment is not uniform. High overhead due to passive allocation mechanism.

Class Fencing - Hit Rate Concavity  Concavity theorem: Regardless of the database reference pattern, hit rate as a function of buffer memory allocation is a concave function under an optimal replacement policy.  Empirical study shows that modern page replacement policy are good enough, no knees!

Class Fencing - Hit Rate Estimator

Class Fencing ’ s - Memory Allocation  A compromise between 2 previous approaches  Local buffer manager VS global buffer manager, shared disk-page-to-buffer-frame table  poolSize, the max. number of buffer frames, is determined by hit rate estimator for one class.  existing DBMS replacement policy applied when demanding pages.

Sharing Between Classes  Sharing: one class can reference a frame outside its fence.  poolSize represents lower bound on the number of frames used by one class, whereas hit rate estimator works with total number of frames used the class.  nonLocal[C] = bufSize – poolSize[C] p = (inUse[C] - numLocal[C]) / nonLocal[C] inUse[C] est = poolSize[C] + △ poolSize + p * (nonLocal[C] - △ poolSize)

Experiments and Results  TPC-C and DBMIN Q2 Goals for Q2 only Goals for TPC-C only Goals for Q2 and TPC-C  DBMIN Q2 and DBMIN Q3 Goals for Q2 only Goals for Q2 and Q3

Conclusion  An improvement of the two previous approaches  Stable and accurate HIGH responsiveness  Low overhead, allow sharing  Robust

Discussion  Why the goal of stability is in conflict of responsiveness?  For class fencing when the hit rate have knees, how do we find the intercept point of HT and hit rate curve?  Is it always possible that the hit rate estimator algorithm can converge to the correct point?