[
https://issues.apache.org/jira/browse/IMPALA-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831093#comment-16831093
]
Tim Armstrong commented on IMPALA-5229:
---------------------------------------
We don't support it - it comes with major pitfalls - essentially hugetlbfs
pushes memory management problems from the OS onto administrators and
applications.
The big administrative pitfall is that you need to preallocate the huge pages
at system startup, and that those pages are not available for regular
allocations. The big technical pitfall is memory fragmentation - the
application has to manage memory in 2MB chunks and avoiding internal and/or
external fragmentation is a major issue.
That's all fine if you have a traditional database running on a dedicated box
and you're willing to jump through hoops to squeeze out some performance, but
that's not the world we're in. I think a lot of other newer database systems
have made similar decisions.
> Try using TCMalloc + Huge Pages for buffers
> -------------------------------------------
>
> Key: IMPALA-5229
> URL: https://issues.apache.org/jira/browse/IMPALA-5229
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> Affects Versions: Impala 2.9.0
> Reporter: Tim Armstrong
> Assignee: Tim Armstrong
> Priority: Major
> Labels: perf, resource-management
> Fix For: Impala 2.9.0
>
>
> As well as mmap() + huge pages, we could support TCMalloc + huge pages. I
> believe TCMalloc will support this well because:
> * We can allocate huge-page-aligned memory via posix_memalign()
> * TCMalloc, by default, always decommits large allocations upon freeing them.
> So if we undo the HUGEPAGE madvise() before handing the pages back to
> TCMalloc, then TCMalloc will decommit the huge pages backing the allocation,
> and we won't get TCMalloc's page heap into a weird state.
> This could give us the perf benefits of huge pages without some of the
> headaches associated with using mmap() directly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
