Toward Efficient In-memory Data Analytics on NUMA Systems

Puya Memarzia; Suprio Ray; Virendra C Bhavsar

REVIEW 3 major objections 5 minor 92 references

Toward Efficient In-memory Data Analytics on NUMA Systems

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper reports that four application-agnostic configuration changes—memory allocator, thread affinity, memory placement, and two OS settings—can yield large speedups for in-memory analytics on NUMA machines.

desk verdict A useful, mostly honest NUMA tuning study whose headline cross-machine claim is only actually demonstrated for two of the four workloads. read the letter →

arxiv 1908.01860 v3 pith:DDNT7XJH submitted 2019-08-05 cs.DB

Puya Memarzia , Suprio Ray , Virendra C Bhavsar This is my paper · ORCID

classification cs.DB

keywords NUMAin-memoryanalyticsmemoryallocatorstbbmallocthreadaffinityplacementpoliciesTransparentHugepagesAuto

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that substantial speedups for in-memory data analytics on NUMA machines are available without rewriting application code: swap the memory allocator, pin threads sparsely, interleave memory pages, and disable the kernel's automatic NUMA balancing and transparent huge pages. The authors report up to a 20x speedup for a hash join on one machine, and up to 43% lower query latency for MonetDB on a TPC-H workload, with gains repeated on three different hardware topologies. They position these as an application-agnostic strategic plan that practitioners can apply with minimal code changes.

What carries the argument

The carrying mechanism is a stack of four application-agnostic configuration choices: (1) overriding the default ptmalloc allocator with a scalable alternative such as tbbmalloc, which gives each thread private memory pools and reduces allocation contention; (2) sparse thread affinity, which prevents the OS from migrating threads and cuts cache misses; (3) memory page interleaving across NUMA nodes, which avoids overloading particular memory controllers; and (4) disabling AutoNUMA load balancing and Transparent Hugepages, which the paper finds are costly for these workloads. The experiments vary each knob while holding the workload fixed, using hardware counters to explain the wins through reduced remote memory access, fewer migrations, and better memory bandwidth utilization.

What would settle it

Re-run the W3 hash join on a current two-socket server with a kernel newer than 5.x, comparing the system-default configuration against the paper's recommended stack; if tbbmalloc plus interleaved memory plus AutoNUMA/THP disabled produces only a modest speedup, or if a newer kernel's improved AutoNUMA and a THP-aware allocator make the default configuration faster, then the paper's general claim about disabling these settings fails for modern systems.

Watch

Extended reading notes

Core claim

The paper's central claim is that the default Linux configuration is systematically suboptimal for memory-intensive analytical workloads, and that a small set of black-box tweaks can recover much of the lost performance. The authors demonstrate this on holistic and distributive aggregations, hash joins, indexed nested-loop joins, and TPC-H queries running on MonetDB and PostgreSQL, across three machines with different NUMA topologies. Their headline results are a 3x speedup for a hash join from switching to the tbbmalloc allocator alone, growing to 20x when combined with memory interleaving and disabled AutoNUMA and THP, plus average MonetDB TPC-H latency improvements of 14.5% from disabling AutoNUMA and THP.

Load-bearing premise

The load-bearing premise is that the three tested machines—with kernels 3.10, 4.4, and 4.15 and glibc versions 2.24 to 2.27—adequately represent modern NUMA behavior well enough that the conclusion to disable AutoNUMA and THP holds regardless of hardware generation.

Editorial extensions

If this is right

A hash join workload can run up to 20x faster on an eight-node machine simply by changing allocator, memory placement, and OS settings, without touching the join code.
MonetDB TPC-H query latency improves by up to 43% when AutoNUMA and THP are disabled, and by up to 20% for join-heavy queries when tbbmalloc replaces the default allocator.
Workloads that frequently allocate memory concurrently benefit most from allocator replacement, while lightweight workloads such as simple count-based aggregation see little gain.
The paper's recommended configuration is to disable AutoNUMA and THP, use interleaved memory placement, and choose a scalable allocator, generalizing across the three tested architectures.
Thread affinity stabilizes run-to-run performance, reducing migration-induced cache invalidation and increasing the ratio of local memory accesses.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If these results generalize, database administrators could adopt a simple default tuning recipe for NUMA servers that contradicts the common practice of relying on kernel heuristics; a testable extension is a sweep over recent kernels where AutoNUMA behavior has changed.
The paper's finding that allocators handle THP poorly suggests allocator-aware huge-page support is an under-explored design space; future allocators could detect THP and adjust their page-size strategies.
The current evidence is restricted to Linux kernels 3.10, 4.4, and 4.15, so an editorial extension would be to validate the same stack on newer kernels and on AMD EPYC or ARM-based NUMA systems, where the relative costs of local and remote access differ.
A further inference is that the same black-box recipe may help other memory-intensive but non-database systems, such as graph analytics and scientific computing, because the mechanisms are application-agnostic.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Two things to know. First, this is a broad, practical empirical study of config-only NUMA tuning: memory allocator, thread affinity, memory placement, and AutoNUMA/THP settings. The individual tricks are known, but the combined evaluation across two DBMSes and three genuinely different NUMA machines is a useful data point. The reported speedups are real and sometimes dramatic: 20x on a hash join from tbbmalloc plus interleaving plus OS setting changes, and 43% latency reduction on MonetDB. Second, the paper overclaims its own evidence. I checked the figures and the stress-test note is right: only W1 (holistic aggregation) and W3 (hash join) are actually shown on all three machines. W2 is only shown on Machine A, and W4 is only shown on Machine A. So the abstract's "four workloads on three hardware architectures" is not supported as published, and Section 6's "regardless of the hardware generation" is definitely too strong. The substance of the paper comes mostly from W1 and W3, so this is a fixable overclaim rather than a broken core.

What is genuinely new: I don't know of another paper that sweeps allocator x placement x OS features across three architectures and two database engines with perf-counter analysis. The allocator microbenchmark that justifies dropping supermalloc and mcmalloc gives a reasoned basis for later experimental choices. The self-cited aggregation workload [51] is used as a benchmark, not as evidence for the tuning conclusions, so there is no circularity problem.

Soft spots, in proportion. The most important is the missing cross-machine panels for W2 and W4; the text should either add them or explicitly limit the multi-machine claim. Second, most figures show single point values without error bars or significance tests; only Figure 3 shows repeated runs. Third, a few choices are made after seeing results (selecting ART, picking TPC-H queries 5 and 18), which is common in this kind of work but should be flagged as exploratory. Fourth, no artifact is shipped, so the numbers cannot be independently reproduced. Fifth, the hardware is old (K8, Nehalem, Broadwell; kernels 3.10-4.15), and Machine B's improvement is only 7%, which cuts against any "regardless of hardware generation" conclusion.

Who this is for: systems practitioners who want a black-box checklist of NUMA settings, and anyone benchmarking database workloads on multi-socket machines. It deserves serious peer review. I would ask the authors to either fill in the missing cross-machine runs or soften the claims, and to report variance on the key numbers. With that revision, I would support acceptance.

Referee Report

3 major / 5 minor

Summary. The paper investigates application-agnostic strategies for improving in-memory data analytics on NUMA systems, specifically memory allocator choice, thread affinity, memory placement policies, and OS-level settings (AutoNUMA and Transparent Hugepages). It presents microbenchmarks and workload experiments covering holistic and distributive aggregation, hash join, index nested-loop join, and TPC-H on MonetDB and PostgreSQL, on three machines with different NUMA topologies. The paper reports large speedups, e.g., up to 20x for a hash join and up to 43% latency reduction for MonetDB, and concludes that default OS configuration is often detrimental and that interleaving, disabling AutoNUMA/THP, and replacing ptmalloc with tbbmalloc are broadly beneficial.

Significance. If the results are reliable, the paper provides a useful, low-effort optimization playbook for practitioners and complements application-level NUMA-aware research. The cross-architecture scope (K8, Nehalem, Broadwell), the inclusion of two real database systems, the profiling data, and the microbenchmark basis for allocator choices are genuine strengths. The speedups are direct measurements, not outputs of a fitted model, so the core empirical direction is credible. However, the strength of the headline generalization is not matched by the displayed evidence: cross-machine data are shown for only two of the four synthetic workloads, and some key assertions about other workloads and machines are made without accompanying figures.

major comments (3)

[§4.4.1, Figures 6–7] The abstract claims significant speedups in "four commonplace in-memory data analytics workloads, on three different hardware architectures," but the displayed evidence covers only W1 and W3 on all three machines. W2 appears in a single panel labeled "Machine A" (Figure 6h), and W4 appears only in Figure 7, captioned "Machine A." The sentence in §4.4.1 that Figure 6 shows W2 "running on each of our three machines" is contradicted by the figure. Since Section 6 then generalizes "regardless of the hardware generation," the cross-machine basis for that generalization is two workloads, not four. Please either add the missing Machine B/C results for W2 and W4 or explicitly qualify the claims in the abstract, Section 4.4.1, and Section 6.
[§4.3.1] The paper states that the AutoNUMA results "were obtained using W1 on Machine A, but we observed very similar results on the other workloads and machines." No supporting figure or table is provided for the other workloads or machines. This is load-bearing because the conclusion to disable AutoNUMA and THP "regardless of the hardware generation" depends on this generalization. Please provide the supporting measurements or narrow the claim to the configurations actually shown.
[Figures 5–9] The main performance figures report single point values with no error bars, no repeated-run statistics, and no significance tests. Figure 3 itself demonstrates that the default OS scheduler can produce run-to-run variation of roughly an order of magnitude, so point estimates are not self-justifying for a benchmark paper whose central claim is about "significant speedups." Report at least the median and range (or interquartile range) over multiple runs for the headline configurations, or otherwise justify that the reported differences exceed run-to-run noise.

minor comments (5)

[§4.1 and Table 3] The text says each Machine C processor has "768MB of memory," while Table 3 says "768GB/node" and the total is 3TB; one of these is a typo.
[§4.4.2] This section refers to the "Heavy Hitter dataset" as the default for W1, but Section 4.2 defines the aggregation datasets as Moving Cluster, Sequential, and Zipfian; please define or rename "Heavy Hitter" for consistency.
[Figure 3] The y-axis is relative runtime on a log scale, and the text says the affinitized case is "several orders of magnitude faster" in the best case; the caption should state the normalization and the log scale explicitly.
[§5, reference [37]] The citation for Kiefer et al. lists "BTW 2025," but the paper is from 2013; please verify and correct the venue/year.
[Throughout] There are several typographical issues: "PostGreSQL" (Section 4.5), "Univeristy" in the author affiliations, and "Diﬀ" in Table 2; a final proofreading pass would be helpful.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's speedup claims are direct measurements of workloads under different system configurations, not outputs of a fitted model or a self-referential derivation.

full rationale

This is an empirical benchmarking paper. Every central claim—e.g., that tbbmalloc, memory interleaving, thread affinity, and disabling AutoNUMA/THP yield speedups—is supported by measured execution times or latencies reported in Figures 5-9. There is no fitted parameter that is later renamed as a prediction, and no equation in which the output is defined in terms of the input. The only notable self-citation is reference [51] (Memarzia, Ray, and Bhavsar), which is cited as the source of the aggregation workload implementation and its dataset distributions; this is a benchmark provenance citation, not load-bearing evidence for the paper's conclusions. The paper does not invoke a uniqueness theorem, does not import a contested premise from the authors' prior work, and does not rename a known result as an organizing principle. Consequently, the derivation chain is self-contained with respect to the measured claims, and the score is 0. Whether the cross-machine evidence actually covers all four synthetic workloads (the published figures show W1 and W3 on all three machines, while W2 and W4 appear only on Machine A) is a correctness/completeness concern, not a circularity concern.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No model parameters are fitted to data; the paper reports direct measurements. Its assumptions are about representativeness of benchmarks, machines, and baselines. No new entities are postulated.

assumptions (3)

domain assumption The five workloads and synthetic datasets are representative of in-memory data analytics.
Section 4.2 introduces the workloads, but no external validation shows they predict production query performance; the generality claim depends on this.
domain assumption The measured performance differences reflect the manipulated configuration rather than unmeasured environmental factors.
Section 4.1 describes the machines and software, but no statistical controls or error bars are reported, so this assumption is unverified.
domain assumption The default Linux configuration (ptmalloc, First Touch, AutoNUMA and THP enabled) is the appropriate baseline for evaluating default behavior.
Sections 3.4 and 4.3 treat these defaults as the baseline; deployments that already disable THP or AutoNUMA would see smaller gains.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Toward Efficient In-memory Data Analytics on NUMA Systems." pith.science (2026). https://pith.science/paper/DDNT7XJH

@misc{pith2026190801860,
  author       = {Pith},
  title        = {Pith review of: Toward Efficient In-memory Data Analytics on NUMA Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DDNT7XJH}},
  note         = {Machine review of arXiv:1908.01860}
}

read the original abstract

Data analytics systems commonly utilize in-memory query processing techniques to achieve better throughput and lower latency. Modern computers increasingly rely on Non-Uniform Memory Access (NUMA) architectures in order to achieve scalability. A key drawback of NUMA architectures is that many existing software solutions are not aware of the underlying NUMA topology and thus do not take full advantage of the hardware. Modern operating systems are designed to provide basic support for NUMA systems. However, default system configurations are typically sub-optimal for large data analytics applications. Additionally, achieving NUMA-awareness by rewriting the application from the ground up is not always feasible. In this work, we evaluate a variety of strategies that aim to accelerate memory-intensive data analytics workloads on NUMA systems. We analyze the impact of different memory allocators, memory placement strategies, thread placement, and kernel-level load balancing and memory management mechanisms. With extensive experimental evaluation we demonstrate that methodical application of these techniques can be used to obtain significant speedups in four commonplace in-memory data analytics workloads, on three different hardware architectures. Furthermore, we show that these strategies can speed up two popular database systems running a TPC-H workload.

Figures

Figures reproduced from arXiv: 1908.01860 by the authors.

**Figure 2.** Memory Allocator Microbenchmark - Machine A [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 4.** Comparison of two thread affinitization strategies - Holistic Aggregation Workload (W1) - Machine A [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗

Figures from the paper (5 more)

**Figure 5.** Figure 5: Impact of operating system configuration (AutoNUMA and THP) on memory placement policies and memory [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]

**Figure 6.** Figure 6: Comparison of memory allocators - variable memory placement policy [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]

**Figure 7.** Figure 7: Index nested loop join experiments - Machine A [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]

**Figure 8.** Figure 8: Query latency improvement gained from disabling [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]

**Figure 9.** Figure 9: Effect of memory allocator on TPC-H query la [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

92 extracted references · 80 canonical work pages

[51]

Kissinger, T

T. Kissinger, T. Kiefer, B. Schlegel, D. Habich, D. Molka, and W. Lehner. ERIS: A NUMA-aware in-memory storage engine for analytical workloads. Proceedings of the VLDB Endowment , 7(14):1–12, 2014

work page 2014
[1]

Toward Efficient In-memory Data Analytics on NUMA Systems

INTRODUCTION The digital world is producing large volumes of data at increasingly higher rates [76, 34, 68]. Data analytics sys- tems are among the key technologies that power the in- formation age. The breadth of applications that depend on eﬃcient data processing has grown dramatically. Main c© 2019 Copyright held by the owner/author(s). Permission to m...

work page Pith review arXiv 2019
[2]

Dynamic memory allocators (Section 3.1)
[3]

Thread placement and scheduling (Section 3.2)
[4]

Memory placement policies (Section 3.3)
[5]

For instance, the default Linux memory allo- cator ptmalloc can perform poorly compared to other alter- natives

Operating system conﬁguration: virtual memory page size and NUMA load balancing (Section 3.4) An important ﬁnding from our research is that the default operating system environment can be detrimental to query performance. For instance, the default Linux memory allo- cator ptmalloc can perform poorly compared to other alter- natives. Furthermore, with exte...
[6]

Each node consists of one or more processors and their lo- cal memory resources

BACKGROUND A NUMA system is divided into several NUMA nodes. Each node consists of one or more processors and their lo- cal memory resources. Multiple NUMA nodes are linked together using an interconnect to form a NUMA topology. The topology of our machines is shown in Figure 1. A local memory access involves data that resides on the same node, whereas ac...
[7]

We explore application-agnostic 3 strategies that can be applied to the data analytics applica- tion in either a black box manner, or with minimal tweaks to the code

IMPROVING QUERY PERFORMANCE ON NUMA SYSTEMS Achieving good performance on NUMA systems involves careful consideration of thread placement, memory manage- ment, and load balancing. We explore application-agnostic 3 strategies that can be applied to the data analytics applica- tion in either a black box manner, or with minimal tweaks to the code. Some strat...

work page arXiv 2017

Show all 92 references

[8]

In Section 4.1 we outline the speciﬁcations of our machines, as well as the software conﬁguration

EV ALUATION In this section, we describe our setup, and evaluate the eﬀectiveness of our techniques. In Section 4.1 we outline the speciﬁcations of our machines, as well as the software conﬁguration. We begin by analyzing the impact of the operating system conﬁguration in Sect...
[9]

We now explore some of works in this context that are relevant to query processing and data analytics

RELATED WORK The rising demand for high performance parallel comput- ing has motivated many works on leveraging NUMA archi- tectures. We now explore some of works in this context that are relevant to query processing and data analytics. 11 In [37], Kiefer et al. evaluated the ...
[10]

Burke and M

M. Burke and M. L. Soﬀa, editors. ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI). ACM, 2001

2001
[11]

Our experiments on ﬁve analytics work- loads have shown that it is possible to obtain signiﬁcant speedups by utilizing these strategies

CONCLUSION In this work, we have provided empirical evidence and analysis to support the importance of using application- agnostic strategies to speedup data analytics workloads on NUMA machines. Our experiments on ﬁve analytics work- loads have shown that it is possible to ob...
[12]

ACKNOWLEDGEMENTS We would like to thank Kenneth Kent and Aaron Gra- ham from IBM CASA and Serguei Vassiliev and Kaizaad Bilimorya from Compute Canada, for providing access to Machine B and Machine C respectively. 12
[13]

Asanovic et al

K. Asanovic et al. The landscape of parallel computing research: A view from berkeley. Technical report, Technical Report UCB/EECS-2006-183, University of California, Berkeley, 2006

2006
[14]

Balkesen et al

C. Balkesen et al. Main-memory hash joins on multi-core CPUs: Tuning to the underlying hardware. In ICDE, 2013

2013
[15]

Baumann, P

A. Baumann, P. Barham, P.-E. Dagand, T. Harris, R. Isaacs, S. Peter, T. Roscoe, A. Sch¨ upbach, and A. Singhania. The multikernel: A new os architecture for scalable multicore systems. In ACM SIGOPS Symposium on Operating Systems Principles (SOSP) , SOSP ’09, pages 29–44, 2009

2009
[16]

Baumann, P

A. Baumann, P. Barham, P.-E. Dagand, T. Harris, R. Isaacs, S. Peter, T. Roscoe, A. Sch¨ upbach, and A. Singhania. The multikernel: a new OS architecture for scalable multicore systems. In ACM SIGOPS Symposium on Operating Systems Principles (SOSP) , pages 29–44. ACM, 2009

2009
[17]

E. D. Berger et al. Hoard: A scalable memory allocator for multithreaded applications. ACM SIGARCH, 28(5), 2000

2000
[18]

E. D. Berger, B. G. Zorn, and K. S. McKinley. Composing high-performance memory allocators. In Burke and Soﬀa [10], pages 114–124
[19]

Blagodurov et al

S. Blagodurov et al. A case for NUMA-aware contention management on multicore systems. In PACT, 2010

2010
[20]

Blanas et al

S. Blanas et al. Design and evaluation of main memory hash join algorithms for multi-core CPUs. In SIGMOD, 2011

2011
[21]

Boyd-Wickizer, H

S. Boyd-Wickizer, H. Chen, R. Chen, Y. Mao, F. Kaashoek, R. Morris, A. Pesterev, L. Stein, M. Wu, Y. Dai, Y. Zhang, and Z. Zhang. Corey: An operating system for many cores. In USENIX Conference on Operating Systems Design and Implementation (OSDI), OSDI’08, pages 43–57, 2008

2008
[22]

Gepner and M

P. Gepner and M. F. Kowalik. Multi-core processors: New way to achieve high system performance. In International Symposium on Parallel Computing in Electrical Engineering (PARELEC’06), pages 9–13. IEEE, 2006

2006
[23]

Chen and M

Q. Chen and M. Guo. Contention and locality-aware work-stealing for iterative applications in multi-socket computers. IEEE Transactions on Computers , 67(6):784–798, 2017

2017
[24]

Cieslewicz and K

J. Cieslewicz and K. A. Ross. Adaptive aggregation on chip multiprocessors. In VLDBJ, 2007

2007
[25]

J. Corbet. AutoNUMA: the other approach to NUMA scheduling. LWN. net, 2012

2012
[26]

T. P. P. Council. TPC-H benchmark speciﬁcation 2.17.3. Published at tpc.org/tpch, 2017

2017
[27]

Dashti et al

M. Dashti et al. Traﬃc management: a holistic approach to memory placement on NUMA systems. SIGPLAN Notices, 48(4), 2013

2013
[28]

D. Dice, T. Harris, A. Kogan, and Y. Lev. The inﬂuence of malloc placement on TSX hardware transactional memory. arXiv preprint arXiv:1504.04640, 2015

2015 arXiv
[29]

Diener et al

M. Diener et al. Aﬃnity-based thread and data mapping in shared memory systems. CSUR, 49(4), 2017

2017
[30]

J. Evans. A scalable concurrent malloc (3) implementation for FreeBSD. In BSDCan, 2006

2006
[31]

J. Evans. Jemalloc wiki. github.com/jemalloc/ jemalloc/wiki/Background, 2017

2017
[32]

Funston, M

J. Funston, M. Lorrillere, A. Fedorova, B. Lepers, D. Vengerov, J.-P. Lozi, and V. Quema. Placement of virtual containers on NUMA systems: A practical and comprehensive model. In USENIX Annual Technical Conference (USENIX ATC 18), pages 281–294, Boston, MA, 2018. USENIX Association

2018
[33]

F. Gaud, B. Lepers, J. Funston, M. Dashti, A. Fedorova, V. Qu´ ema, R. Lachaize, and M. Roth. Challenges of memory management on modern NUMA systems. Communications of the ACM , 58(12):59–66, 2015

2015
[34]

Kambatla, G

K. Kambatla, G. Kollias, V. Kumar, and A. Grama. Trends in big data analytics. Journal of Parallel and Distributed Computing, 74(7):2561–2573, 2014

2014
[35]

Ghemawat and P

S. Ghemawat and P. Menage. Tcmalloc: Thread-caching malloc. github.com/gperftools/, 2015

2015
[36]

J. Giceva. Operating Systems Support for Data Management on Modern Hardware. sites.computer.org/debull/A19mar/p36.pdf, 2019

2019
[37]

Giceva, G

J. Giceva, G. Alonso, T. Roscoe, and T. Harris. Deployment of query plans on multicores. Proceedings of the VLDB Endowment , 8(3):233–244, 2014

2014
[38]

Giceva, A

J. Giceva, A. Sch¨ upbach, G. Alonso, and T. Roscoe. Towards database/operating system co-design. In Proceedings of the 2nd workshop on Systems for Future Multi-core Architectures (April 2012), SFMA, volume 12. Citeseer, 2012

2012
[39]

Giceva, G

J. Giceva, G. Zellweger, G. Alonso, and T. Rosco. Customized OS support for data-processing. In Proceedings of the 12th International Workshop on Data Management on New Hardware (DaMoN) , page 2. ACM, 2016

2016
[40]

Gray et al

J. Gray et al. Quickly generating billion-record synthetic databases. Sigmod Record, 23(2), 1994

1994
[41]

W. S. Gray. Non-uniform memory access (NUMA) resource assignment and re-evaluation, Aug. 21 2014. US Patent App. 14/178,810

2014
[42]

Hager, G

G. Hager, G. Wellein, and J. Treibig. LIKWID: A Lightweight Performance-Oriented Tool Suite for x86 Multicore Environments. In International Conference on Parallel Processing Workshops , pages 207–216. IEEE Computer Society, 2010

2010
[43]

R. L. Hudson, B. Saha, A.-R. Adl-Tabatabai, and B. C. Hertzberg. Mcrt-malloc: a scalable transactional memory allocator. In International symposium on Memory management, pages 74–83. ACM, 2006

2006
[44]

M. Inc. The MongoDB 4.0 Manual. docs.mongodb.com/manual/tutorial/ transparent-huge-pages/, 2019

2019
[45]

Their approach uses dynamic task stealing in order to deal with dataset skew

presented a NUMA-aware parallel scheduling algorithm for hash joins. Their approach uses dynamic task stealing in order to deal with dataset skew. Schuh et al. [66] con- ducted an in-depth analysis of thirteen main memory join algorithms on a NUMA system. The authors conducted...
[46]

Kaestle, R

S. Kaestle, R. Achermann, T. Roscoe, and T. Harris. Shoal: Smart Allocation and Replication of Memory For Parallel Programs. In USENIX Annual Technical Conference (USENIX ATC 15), pages 263–276, Santa Clara, CA, 2015. USENIX Association. 13

2015
[47]

U. R. Karpuzcu, B. Greskamp, and J. Torrellas. The bubblewrap many-core: popping cores for sequential acceleration. In 2009 42nd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), pages 447–458. IEEE, 2009

2009
[48]

Kemper and T

A. Kemper and T. Neumann. HyPer: A hybrid OLTP&OLAP main memory database system based on virtual memory snapshots. In IEEE International Conference on Data Engineering (ICDE) , pages 195–206. IEEE, 2011

2011
[49]

Kiefer, B

T. Kiefer, B. Schlegel, and W. Lehner. Experimental evaluation of numa eﬀects on database management systems. Datenbanksysteme f¨ ur Business, Technologie und Web (BTW) 2025 , 2013

2025
[50]

Kim and M

W. Kim and M. Voss. Multicore desktop programming with intel threading building blocks. IEEE software, 28(1), 2011

2011
[52]

Kukanov and M

A. Kukanov and M. J. Voss. The Foundations for Scalable Multi-core Software in Intel Threading Building Blocks. Intel Technology Journal, 11(4), 2007

2007
[53]

B. C. Kuszmaul. SuperMalloc: a super fast multithreaded malloc for 64-bit machines. In ACM SIGPLAN Notices, volume 50, pages 41–55. ACM, 2015

2015
[54]

Y. Kwon, H. Yu, S. Peter, C. J. Rossbach, and E. Witchel. Coordinated and eﬃcient huge page management with ingens. In USENIX Symposium on Operating Systems Design and Implementation (OSDI 16), pages 705–721. USENIX Association, 2016

2016
[55]

Lang et al

H. Lang et al. Massively Parallel NUMA-Aware Hash Joins. In IMDM, 2013

2013
[56]

D. Lea. Dong lea’s malloc (dlmalloc). gee.cs.oswego.edu/dl/html/malloc.html, 2000

2000
[57]

Leis et al

V. Leis et al. Morsel-driven parallelism: a NUMA-aware query evaluation framework for the many-core age. In SIGMOD. ACM, 2014

2014
[58]

V. Leis, F. Scheibner, A. Kemper, and T. Neumann. The ART of practical synchronization. In DaMoN, pages 1–8. ACM, 2016

2016
[59]

Lepers et al

B. Lepers et al. Thread and Memory Placement on NUMA Systems: Asymmetry Matters. In USENIX ATC, 2015

2015
[60]

Li et al

X. Li et al. Algorithmic improvements for fast concurrent cuckoo hashing. In EuroSys. ACM, 2014

2014
[61]

Y. Mao, E. Kohler, and R. T. Morris. Cache craftiness for fast multicore key-value storage. In Proceedings of the 7th ACM european conference on Computer Systems, pages 183–196. ACM, 2012

2012
[62]

S. A. McKee et al. Reﬂections on the memory wall. In Conf. Computing Frontiers, page 162, 2004

2004
[63]

Memarzia, S

P. Memarzia, S. Ray, and V. C. Bhavsar. A Six-dimensional Analysis of In-memory Aggregation. In International Conference on Extending Database Technology (EDBT), pages 289–300, 2019

2019
[64]

Molka, D

D. Molka, D. Hackenberg, R. Sch¨ one, and W. E. Nagel. Cache coherence protocol and memory performance of the intel haswell-ep architecture. In International Conference on Parallel Processing (ICPP), pages 739–748. IEEE, 2015

2015
[65]

MonetDB B.V. MonetDB. monetdb.org, 2018

2018
[66]

S. L. Olivier et al. Openmp task scheduling strategies for multicore numa systems. IJHPCA, 26(2), 2012

2012
[67]

Grid Infrastructure Installation and Upgrade Guide for Linux

Oracle. Grid Infrastructure Installation and Upgrade Guide for Linux. docs.oracle.com/en/database/ oracle/oracle-database/12.2/cwlin/ disabling-transparent-hugepages.html, 2019

2019
[68]

Porobic, E

D. Porobic, E. Liarou, P. Tozun, and A. Ailamaki. Atrapos: Adaptive transaction processing on hardware islands. pages 688–699, 03 2014

2014
[69]

D. M. Powers. Applications and explanations of Zipf’s law. In NeMLaP3/CoNLL98, pages 151–160. Association for Computational Linguistics, 1998

1998
[70]

Psaroudakis et al

I. Psaroudakis et al. Scaling up concurrent main-memory column-store scans: towards adaptive NUMA-aware data and task placement. VLDBJ, 8(12), 2015

2015
[71]

Psaroudakis, S

I. Psaroudakis, S. Kaestle, M. Grimmer, D. Goodman, J.-P. Lozi, and T. Harris. Analytics with smart arrays: adaptive and eﬃcient language-independent data. In Proceedings of the Thirteenth EuroSys Conference, page 17. ACM, 2018

2018
[72]

Psaroudakis, T

I. Psaroudakis, T. Scheuer, N. May, A. Sellami, and A. Ailamaki. Adaptive NUMA-aware Data Placement and Task Scheduling for Analytical Workloads in Main-memory Column-stores. Proc. VLDB Endow., 10(2):37–48, Oct. 2016

2016
[73]

W. Pugh. Skip lists: a probabilistic alternative to balanced trees. Communications of the ACM , 33(6), 1990

1990
[74]

Red Hat Enterprise Linux Product Documentation, 2018

Red Hat Inc. Red Hat Enterprise Linux Product Documentation, 2018

2018
[75]

Red Hat Performance Tuning Guide

Red Hat Inc. Red Hat Performance Tuning Guide. access.redhat.com/documentation/en-us/ red_hat_enterprise_linux/6/html/ performance_tuning_guide/ s-memory-transhuge, 2018

2018
[76]

Redis latency problems troubleshooting

Redis. Redis latency problems troubleshooting. redis.io/topics/latency, 2019

2019
[77]

B. M. Rogers, A. Krishna, G. B. Bell, K. Vu, X. Jiang, and Y. Solihin. Scaling the bandwidth wall: challenges in and avenues for cmp scaling. ACM SIGARCH Computer Architecture News, 37(3):371–382, 2009

2009
[78]

Schuh et al

S. Schuh et al. An experimental comparison of thirteen relational equi-joins in main memory. In SIGMOD, 2016

2016
[79]

Singh, S

T. Singh, S. Rangarajan, D. John, C. Henrion, S. Southard, H. McIntyre, A. Novak, S. Kosonocky, R. Jotwani, A. Schaefer, et al. 3.2 zen: A next-generation high-performance× 86 core. In IEEE International Solid-State Circuits Conference (ISSCC), pages 52–53. IEEE, 2017

2017
[80]

Sivarajah, M

U. Sivarajah, M. M. Kamal, Z. Irani, and V. Weerakkody. Critical analysis of big data 14 challenges and analytical methods. Journal of Business Research, 70:263–286, 2017

2017
[81]

Srikanthan, S

S. Srikanthan, S. Dwarkadas, and K. Shen. Data sharing or resource contention: Toward performance transparency on multicore systems. In USENIX Annual Technical Conference (USENIX ATC 15) , pages 529–540. USENIX Association, 2015

2015
[82]

Stonebraker and A

M. Stonebraker and A. Weisberg. The VoltDB Main Memory DBMS. IEEE Data Eng. Bull. , 36(2):21–27, 2013

2013
[83]

Team et al

G. Team et al. GCC, the gnu compiler collection. gcc.gnu.org, 2019

2019
[84]

The GNU C Library (glibc)

The glibc project developers. The GNU C Library (glibc). gnu.org/software/libc/, 2019

2019
[85]

PostgreSQL

The PostgreSQL Global Development Group. PostgreSQL. postgresql.org, 2019

2019
[86]

Umayabara and H

A. Umayabara and H. Yamana. MCMalloc: A scalable memory allocator for multithreaded applications on a many-core shared-memory machine. In 2017 IEEE International Conference on Big Data (Big Data) , pages 4846–4848. IEEE, 2017

2017
[87]

Van Riel

H. Van Riel. Memory distribution across multiple non-uniform memory access nodes, Oct. 10 2017. US Patent 9,785,581

2017
[88]

R. L. Villars, C. W. Olofson, and M. Eastwood. Big data: What it is and why you should care. White Paper, IDC, 14:1–14, 2011

2011
[89]

S. Vokes. skiplist. github.com/silentbicycle/skiplist, 2016

2016
[90]

Wang et al

L. Wang et al. NUMA-aware scalable and eﬃcient in-memory aggregation on large domains. TKDE, 27(4), 2015

2015
[91]

W. Wang, J. W. Davidson, and M. L. Soﬀa. Predicting the memory bandwidth and optimal core allocations for multi-threaded applications on large-scale NUMA machines. In IEEE International Symposium on High Performance Computer Architecture (HPCA), pages 419–431. IEEE, 2016

2016
[92]

Wentzlaﬀ and A

D. Wentzlaﬀ and A. Agarwal. Factored operating systems (fos): The case for a scalable operating system for multicores. SIGOPS Oper. Syst. Rev. , 43(2):76–85, Apr. 2009. 15

2009

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [51]

Kissinger, T

T. Kissinger, T. Kiefer, B. Schlegel, D. Habich, D. Molka, and W. Lehner. ERIS: A NUMA-aware in-memory storage engine for analytical workloads. Proceedings of the VLDB Endowment , 7(14):1–12, 2014

work page 2014

[2] [1]

Toward Efficient In-memory Data Analytics on NUMA Systems

INTRODUCTION The digital world is producing large volumes of data at increasingly higher rates [76, 34, 68]. Data analytics sys- tems are among the key technologies that power the in- formation age. The breadth of applications that depend on eﬃcient data processing has grown dramatically. Main c© 2019 Copyright held by the owner/author(s). Permission to m...

work page Pith review arXiv 2019

[3] [2]

Dynamic memory allocators (Section 3.1)

[4] [3]

Thread placement and scheduling (Section 3.2)

[5] [4]

Memory placement policies (Section 3.3)

[6] [5]

For instance, the default Linux memory allo- cator ptmalloc can perform poorly compared to other alter- natives

Operating system conﬁguration: virtual memory page size and NUMA load balancing (Section 3.4) An important ﬁnding from our research is that the default operating system environment can be detrimental to query performance. For instance, the default Linux memory allo- cator ptmalloc can perform poorly compared to other alter- natives. Furthermore, with exte...

[7] [6]

Each node consists of one or more processors and their lo- cal memory resources

BACKGROUND A NUMA system is divided into several NUMA nodes. Each node consists of one or more processors and their lo- cal memory resources. Multiple NUMA nodes are linked together using an interconnect to form a NUMA topology. The topology of our machines is shown in Figure 1. A local memory access involves data that resides on the same node, whereas ac...

[8] [7]

We explore application-agnostic 3 strategies that can be applied to the data analytics applica- tion in either a black box manner, or with minimal tweaks to the code

IMPROVING QUERY PERFORMANCE ON NUMA SYSTEMS Achieving good performance on NUMA systems involves careful consideration of thread placement, memory manage- ment, and load balancing. We explore application-agnostic 3 strategies that can be applied to the data analytics applica- tion in either a black box manner, or with minimal tweaks to the code. Some strat...

work page arXiv 2017