Cache craftiness for fast multicore key-value storage

Mao, Yandong; Kohler, Eddie; Morris, Robert

doi:10.1145/2168836.2168855

Cited by 349 publications

(188 citation statements)

References 26 publications

Supporting

Mentioning

179

Contrasting

Order By: Relevance

“…Query terms are chosen randomly, following a Zipfian distribution, which has been shown to model online search query distributions well [7,20]. masstree [35] is a fast, scalable in-memory key-value store written in C++. In-memory key-value stores serve as data storage backends for a wide variety of services.…”

Section: Tailbench Applicationsmentioning

confidence: 99%

“…Key-value stores handle large amounts of data, which is split up into memory-resident shards spread across hundreds of servers. Each user request often involves many tens or hundreds of requests to the key-value store; these applications therefore have very short latency requirements, e.g., about 100 µs [32,35]. While there are many open-source key-value stores, we chose masstree since it is highly optimized to make efficient use of the memory hierarchy of modern multicores.…”

Section: Tailbench Applicationsmentioning

confidence: 99%

See 1 more Smart Citation

Tailbench: a benchmark suite and evaluation methodology for latency-critical applications

Kasture

Sánchez

2016

2016 IEEE International Symposium on Workload Characterization (IISWC)

143

View full text Add to dashboard Cite

Abstract-Latency-critical applications, common in datacenters, must achieve small and predictable tail (e.g., 95 th or 99 th percentile) latencies. Their strict performance requirements limit utilization and efficiency in current datacenters. These problems have sparked research in hardware and software techniques that target tail latency. However, research in this area is hampered by the lack of a comprehensive suite of latency-critical benchmarks.We present TailBench, a benchmark suite and evaluation methodology that makes latency-critical workloads as easy to run and characterize as conventional, throughput-oriented ones. TailBench includes eight applications that span a wide range of latency requirements and domains, and a harness that implements a robust and statistically sound load-testing methodology. The modular design of the TailBench harness facilitates multiple load-testing scenarios, ranging from multi-node configurations that capture network overheads, to simplified single-node configurations that allow measuring tail latency in simulation. Validation results show that the simplified configurations are accurate for most applications. This flexibility enables rapid prototyping of hardware and software techniques for latency-critical workloads.

show abstract

Section: Tailbench Applicationsmentioning

confidence: 99%

Section: Tailbench Applicationsmentioning

confidence: 99%

Tailbench: a benchmark suite and evaluation methodology for latency-critical applications

Kasture

Sánchez

2016

2016 IEEE International Symposium on Workload Characterization (IISWC)

143

View full text Add to dashboard Cite

show abstract

“…We use Silo [67] which is a multicore optimized system that utilizes cache-conscious multiversioned Mass-tree design [44] as the data storage and employs optimistic concurrency control protocol that scales well on multicores.…”

Section: Impact Of Distributed Transactions On Tpc-cmentioning

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

“…• masstree, a high-performance in-memory key-value store that achieves speeds similar to memcached [32].…”

Section: Applicationsmentioning

confidence: 99%

Ubik

Kasture

Sánchez

2014

Proceedings of the 19th International Conference on Architectural Support for Programming Languages and Operating Systems

114

View full text Add to dashboard Cite

Chip-multiprocessors (CMPs) must often execute workload mixes with different performance requirements. On one hand, user-facing, latency-critical applications (e.g., web search) need low tail (i.e., worst-case) latencies, often in the millisecond range, and have inherently low utilization. On the other hand, compute-intensive batch applications (e.g., MapReduce) only need high long-term average performance. In current CMPs, latency-critical and batch applications cannot run concurrently due to interference on shared resources. Unfortunately, prior work on quality of service (QoS) in CMPs has focused on guaranteeing average performance, not tail latency.In this work, we analyze several latency-critical workloads, and show that guaranteeing average performance is insufficient to maintain low tail latency, because microarchitectural resources with state, such as caches or cores, exert inertia on instantaneous workload performance. Last-level caches impart the highest inertia, as workloads take tens of milliseconds to warm them up. When left unmanaged, or when managed with conventional QoS frameworks, shared last-level caches degrade tail latency significantly. Instead, we propose Ubik, a dynamic partitioning technique that predicts and exploits the transient behavior of latency-critical workloads to maintain their tail latency while maximizing the cache space available to batch applications. Using extensive simulations, we show that, while conventional QoS frameworks degrade tail latency by up to 2.3×, Ubik simultaneously maintains the tail latency of latency-critical workloads and significantly improves the performance of batch applications.

show abstract

Cache craftiness for fast multicore key-value storage

Cited by 349 publications

References 26 publications

Tailbench: a benchmark suite and evaluation methodology for latency-critical applications

Tailbench: a benchmark suite and evaluation methodology for latency-critical applications

Characterization of the Impact of Hardware Islands on OLTP

Ubik

Contact Info

Product

Resources

About