A scalable lock manager for multicores

Jung, Hyungsoo; Han, Hyuck; Fekete, Alan; Heiser, Gernot; Yeom, Heon Y.

doi:10.1145/2463676.2465271

Cited by 35 publications

(15 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Lock Table: As identified in previous work [26,36], the lock table is another key contention point in DBMSs. Instead of having a centralized lock table or timestamp manager, we implemented these data structures in a per-tuple fashion where each transaction only latches the tuples that it needs.…”

Section: General Optimizationsmentioning

confidence: 98%

“…In recent years, there have been several efforts towards improving the shortcomings of these classical implementations [11,24,32,42]. Other work includes standalone lock managers that are designed to be more scalable on multi-core CPUs [36,26]. We now describe these systems in further detail and discuss why they are still unlikely to scale on future many-core architectures.…”

Section: Related Workmentioning

confidence: 99%

“…Implementing a system from scratch allows us to avoid any artificial bottlenecks in existing DBMSs and instead understand the more fundamental issues in the algorithms. Previous scalability studies used existing DBMSs [24,26,32], but many of the legacy components of these systems do not target many-core CPUs. To the best of our knowledge, there has not been an evaluation of multiple concurrency control algorithms on a single DBMS at such large scale.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Staring into the abyss

Yu¹,

Bezerra²,

Pavlo

et al. 2014

Proc. VLDB Endow.

174

View full text Add to dashboard Cite

Computer architectures are moving towards an era dominated by many-core machines with dozens or even hundreds of cores on a single chip. This unprecedented level of on-chip parallelism introduces a new dimension to scalability that current database management systems (DBMSs) were not designed for. In particular, as the number of cores increases, the problem of concurrency control becomes extremely challenging. With hundreds of threads running in parallel, the complexity of coordinating competing accesses to data will likely diminish the gains from increased core counts.To better understand just how unprepared current DBMSs are for future CPU architectures, we performed an evaluation of concurrency control for on-line transaction processing (OLTP) workloads on many-core chips. We implemented seven concurrency control algorithms on a main-memory DBMS and using computer simulations scaled our system to 1024 cores. Our analysis shows that all algorithms fail to scale to this magnitude but for different reasons. In each case, we identify fundamental bottlenecks that are independent of the particular database implementation and argue that even state-of-the-art DBMSs suffer from these limitations. We conclude that rather than pursuing incremental solutions, many-core chips may require a completely redesigned DBMS architecture that is built from ground up and is tightly coupled with the hardware.

show abstract

Section: General Optimizationsmentioning

confidence: 98%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Staring into the abyss

Yu¹,

Bezerra²,

Pavlo

et al. 2014

Proc. VLDB Endow.

174

View full text Add to dashboard Cite

show abstract

“…Several studies focus on scaling traditional disk-based OLTP engines on multi-cores by eliminating scalability bottlenecks caused by global latching on centralized data structures [15,17,18,19,20,22]. As modern mainmemory OLTP engines [11,23,24] avoid such overheads by design, they scale much better than their disk-based counterparts.…”

Section: Related Workmentioning

confidence: 99%

Analyzing the impact of system architecture on the scalability of OLTP engines for high-contention workloads

et al. 2017

View full text Add to dashboard Cite

Main-memory OLTP engines are being increasingly deployed on multicore servers that provide abundant thread-level parallelism. However, recent research has shown that even the state-of-the-art OLTP engines are unable to exploit available parallelism for high contention workloads. While previous studies have shown the lack of scalability of all popular concurrency control protocols, they consider only one system architecture-a non-partitioned, shared everything one where transactions can be scheduled to run on any core and can access any data or metadata stored in shared memory.In this paper, we perform a thorough analysis of the impact of other architectural alternatives (Data-oriented transaction execution, Partitioned Serial Execution, and Delegation) on scalability under high contention scenarios. In doing so, we present Trireme, a main-memory OLTP engine testbed that implements four system architectures and several popular concurrency control protocols in a single code base. Using Trireme, we present an extensive experimental study to understand i) the impact of each system architecture on overall scalability, ii) the interaction between system architecture and concurrency control protocols, and iii) the pros and cons of new architectures that have been proposed recently to explicitly deal with high-contention workloads.

show abstract

“…These characteristics make distributed memories (as those of multisockets), distributed caches (as those of multicores), and prefetchers ineffective. A lot of recent techniques aim to improve scalability of individual components of traditional systems, including locking, latching and logging on multicores by specializing synchronization primitives to a particular component [26,29,31,34]. Recent work suggests a departure from the traditional transaction-oriented execution model, to adopt a data-oriented execution model, circumventing the aforementioned properties -and flaws -of traditional sharedeverything OLTP [35,47,48].…”

Section: Shared-everything Database Deploymentsmentioning

confidence: 99%

Characterization of the Impact of Hardware Islands on OLTP

Porobic

Pandis

Branco³

et al. 2015

The VLDB Journal

View full text Add to dashboard Cite

Modern hardware is abundantly parallel and increasingly heterogeneous. The numerous processing cores have non-uniform access latencies to the main memory and processor caches, which causes variability in the communication costs. Unfortunately, database systems mostly assume that all processing cores are the same and that microarchitecture differences are not significant enough to appear in critical database execution paths. As we demonstrate in this paper, however, non-uniform core topology does appear in the critical path and conventional database architectures achieve suboptimal and even worse, unpredictable performance. We perform a detailed performance analysis of OLTP deployments in servers with multiple cores per CPU (multicore) and multiple CPUs per server (multisocket). We compare different database deployment strategies where we vary the number and size of independent database instances running on a single server, from a single shared-everything instance to fine-grained shared-nothing configurations. We quantify the impact of non-uniform hardware on various deployments by (a) examining how efficiently each deployment uses the available hardware resources and (b) measuring the impact of distributed transactions and skewed requests on different workloads. We show that no strategy is optimal for all cases and that the best choice depends on the combination of hardware topology and workload characteristics. Finally, we argue that transaction processing systems must be aware of the hardware topology in order to achieve predictably high performance.

show abstract

A scalable lock manager for multicores

Cited by 35 publications

References 29 publications

Staring into the abyss

Staring into the abyss

Analyzing the impact of system architecture on the scalability of OLTP engines for high-contention workloads

Characterization of the Impact of Hardware Islands on OLTP

Contact Info

Product

Resources

About