Increasing Concurrency in Databases using Program Analysis Roman Vitenberg, Kristian Kvilekval and Ambuj Singh University of California, Santa Barbara Ecoop June 15-18 Oslo, Norway.

Download Report

Transcript Increasing Concurrency in Databases using Program Analysis Roman Vitenberg, Kristian Kvilekval and Ambuj Singh University of California, Santa Barbara Ecoop June 15-18 Oslo, Norway.

Increasing Concurrency in
Databases using Program Analysis
Roman Vitenberg, Kristian
Kvilekval and Ambuj Singh
University of California, Santa Barbara
Ecoop June 15-18 Oslo,
Norway
1
Outline
 Motivation
 Shape graphs and prediction
 Predictive scheduler optimizations
 Results
 Conclusions
Ecoop June 15-18 Oslo, Norway
2
Transactional Schedulers
 Most fundamental problem of
concurrency control [Pap86][BHG87]…
 Little has been done on predictive
schedulers


Difficult to extract future usage
Difficult to use it (Optimal Scheduling
NP-complete)
Ecoop June 15-18 Oslo, Norway
3
Program analysis for better
concurrency
 OODB’s increasingly integrated (JDO)
 Shape analysis makes predicting data
accesses more feasible


Transactional code is known in advance
Rich type structure available to analysis
 Enhance schedulers with specific
optimizations based on the extracted info

Deadlock handling, early lock release, adaptive
preclaiming
Ecoop June 15-18 Oslo, Norway
4
Previous and Related Work
 Scheduling in object bases

[Graham&Barker95]
 Shape analysis (pointer analysis)




Escape analysis[Bogda99][Ruf00]
Parallelization[Corbera99]
Type Safety[Ghiya96] [Nurit98]
[Wilhem00]
Others...
Ecoop June 15-18 Oslo, Norway
5
Outline
 Motivation
 Shape graphs and prediction
 Predictive scheduler optimizations
 Results
 Conclusions
Ecoop June 15-18 Oslo, Norway
6
Overview of Prediction
 Predict locking based on program code


Extract program summary in shape graph
Provide runtime system with future accesses
 Advantages



Facilitates integration OODB
Supports complex pointer-based structures
Automatically derived from source code
Ecoop June 15-18 Oslo, Norway
7
Example shape
class Connector{ Part a,b; }
class Part {
Connector left,right,up,down;
Material m
Supplier s;
…
int volume();
}
part
right
part
connector
material
weight=0;
while (part) {
weight+=(part.material.density
*part.volume());
part=part.right.b;
}
Ecoop June 15-18 Oslo, Norway
8
Basic Shape Analysis
 Graph


Abstract locations (heap cells)
Edges labeled with with field names
 Abstract interpretation



Extend graph through field references
Combine graphs when heap location is shared
Merge shapes bottom up through static call
graph
Ecoop June 15-18 Oslo, Norway
9
Predicting with shape
graphs
 Compile Time

Generate shapes for method references



Self, arguments, and global variables
Label shape edges with earliest access
Annotate programs to pass visible references
and shapes to transaction scheduler
 Runtime

Interpret shape graph on the actual object
graph generating expected object set
Ecoop June 15-18 Oslo, Norway
10
Predicting with Shape
Graphs
Object Graph
N:5
a1
F:10
J:10
a2
G:5
a3
o1:0
a4
K:10
F
o2:10
K
N
o4:5
J
o5:15
N
o6:10
J
o3:20
a5
Shape Graph
(o1,a1) » (o4,a1) » (o2,a2) » (o6,a1) » (o5,a4) » (o3,a5)
Ecoop June 15-18 Oslo, Norway
11
Outline
 Motivation
 Shape graphs and prediction
 Predictive scheduler optimizations
 Results
 Conclusions
Ecoop June 15-18 Oslo, Norway
12
Deadlock Handling: Background
 Deadlock detection

Wait-for-graph (WFG)



Nodes are active transactions
Edge (ti,tj) indicates that ti waits for tj to release a lock
Maintaining throughout execution is expensive
 Deadlock prevention

Heuristic-based techniques (wound-wait)


Cheaper but causing unnecessary transaction aborts
Resource allocation graph (infeasible w/o future
knowledge)
Ecoop June 15-18 Oslo, Norway
13
Deadlock handling: our approach
 Shape analysis helps us prune parts of WFG and
other graphs in all graph-based algorithms
Ecoop June 15-18 Oslo, Norway
14
Early lock release: background
 Strict 2PL: all locks are held till the
end of transaction
 Non-strict 2PL: read locks are released
after the last access to the object
 Non-strict allows greater concurrency
but


Difficult to determine the last access
Allows non-serializable execution
Ecoop June 15-18 Oslo, Norway
15
Early lock release: nonsearializable execution
T1 :
Acq(o1)
T2:
read(o1)
Rel (o1)
Acq(o1)
write(o1)
Acq(o2)
write(o2)
Rel(o1,o2)
Acq(o2)
read(o2)
Rel(o2)
Ecoop June 15-18 Oslo, Norway
16
Early lock release: our approach
 Estimate the last access to an object in
order to release early
 Causality-aware scheduler

T1 causally precedes T2 (T1 c T2) if either




T2 is initiated after T1 by the same client, or
T2 acquires a lock that T1 has released, or
There is T3 such that T1 c T3 and T3 c T2
If T1 c T2 the scheduler blocks T2.A(O) if T1
may access O in the future.
Ecoop June 15-18 Oslo, Norway
17
Early lock release: Causalityaware scheduling
T1 :
Acq(o1)
T2:
read(o1)
Rel (o1)
Acq(o1)
write(o1)
Acq(o2)
<- Blocks
write(o2)
Rel(o1,o2)
Acq(o2)
read(o2)
Rel(o2)
Ecoop June 15-18 Oslo, Norway
18
Lock preclaiming: background
 Standard 2PL acquires locks gradually
 Conservative 2PL preclaims all the locks


Fewer aborts upon high contention & long
transactions
Shorter wait-for chains
T1.A(O2)
T2.A(O1)T2.A(O2)
T3.A(O1)

Requires apriori knowledge of locks
Ecoop June 15-18 Oslo, Norway
19
Lock preclaiming: our approach
 Predict the set of objects to be
preclaimed automatically
 Adaptive hybrid schemes


Preclaim when expected contention level
is high across executing transactions
Preclaim locks only for short transaction
Ecoop June 15-18 Oslo, Norway
20
Outline
 Motivation
 Shape graphs and prediction
 Predictive scheduler optimizations
 Results
 Conclusions
Ecoop June 15-18 Oslo, Norway
21
Overview of performance
measurements
 Two applications: OO7 & Prototype
reservation system
 Mix of transaction types (lock sequence,
short/long transactions)
 Transaction rates, and transaction
parameters
 Compare Standard 2PL with our enhanced
2PL based on scheduling delay time
Ecoop June 15-18 Oslo, Norway
22
Evaluation: OO7
•Short Read
•2ms
•600/min
•Short Update
Comp
•2ms
Parts
•10/min
•Long Reorg
•2000ms
•3/min
Ecoop June 15-18 Oslo, Norway
23
OO7 Results
Relative delay by scheduler
ms
100
update
50
query
0
reorg
S2PL
Early Release
Preclaim
Ecoop June 15-18 Oslo, Norway
Both
24
Delays in short query
Strict 2-Phase
Predictive
Ecoop June 15-18 Oslo, Norway
25
Conclusions & future directions
•Runtime use of shape graph can generate object use
prediction (even without prior statistics)
• Transaction scheduler improved by
•Better deadlock handling (smaller WFG)
•Early read lock release
•Lock preclaiming
•Future: lease prediction
Ecoop June 15-18 Oslo, Norway
26
End
Questions?
Ecoop June 15-18 Oslo, Norway
27
Evaluation: Car Reservation
1
2
3
User Rate
300/s
30/s
30/s
User dur
30ms
30ms
30ms
Trav Rate
1/min
1/min
1/min
Trav dur
560ms
560ms
1200ms
Maint rate
6min
2min
2min
Maint dur
6s
6s
6s
Ecoop June 15-18 Oslo, Norway
28
Evaluation: car reservation
Query
60
50
40
30
20
10
0
Traversal
Starved
3423
Starved
S2PL
Pr
5000
Op
0
Conf 1
Conf 2
Conf 3
Conf 1
Ecoop June 15-18 Oslo, Norway
Conf 2
Conf 3
Exec
29
Construction of Shape
Graphs
x
Ecoop June 15-18 Oslo, Norway
30
Construction of Shape
Graphs
x.f = s;
F
Ecoop June 15-18 Oslo, Norway
31
Construction of Shape
Graphs
x.f = s;
t = x.f.g;
F
G
Ecoop June 15-18 Oslo, Norway
32
Construction of Shape
Graphs
x.f = s;
x.f.g = t;
N
F
?
x = x.n;
G
Ecoop June 15-18 Oslo, Norway
33
Construction of Shape
Graphs
N
x.f =
x.f.g
if (x
x =
s;
= t;
!= null)
x.n;
F
G
Ecoop June 15-18 Oslo, Norway
34
Combining Shape Graphs
x = y;
N
F
F
G
K
J
Ecoop June 15-18 Oslo, Norway
35
Combining Shape Graphs
 Unify graphs recursively
N
F
F
G
K
J
Ecoop June 15-18 Oslo, Norway
36
Unification of Shape
Graphs
 Unify graphs recursively
N
N
F
F
G
K
J
F
G
J
K
Ecoop June 15-18 Oslo, Norway
37
Shape Analysis Algorithm
  methods Interpret basic blocks


Create shapes for basic blocks
Run until fixed-point is reached
 Propagate in static callgraph
Ecoop June 15-18 Oslo, Norway
38
Static Call Graphs
Static representation of calls
m3{
a.f = s;
o.m4(a)
}
Class C {
m4(F f) {
…
}
main
m2
m3
m4
Unify(a,f)
f
Ecoop June 15-18 Oslo, Norway
39
Call Graphs
 Propagate bottom up
 Merge polymorphic calls
m1
m2
m3
m4
B.m4
D1.m4
D2.m4
 Recursive Calls


Fixed point
Merge SCC[Ruf00]
m1
m2
m1
Ecoop June 15-18 Oslo, Norway
40
Overview of scheduler
enhancements
 Better Deadlock handling


Smaller WFG based on type information
Conservative Resource Allocation Graph
 Early Lock Release

Read locks released after last use
 Lock Preclaiming

Better throughput in high contention
Ecoop June 15-18 Oslo, Norway
41