You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@druid.apache.org by GitBox <gi...@apache.org> on 2021/05/26 20:35:14 UTC

[GitHub] [druid] wjhypo opened a new pull request #11309: Optionally load segment index files into page cache on bootstrap and new segment download

wjhypo opened a new pull request #11309:
URL: https://github.com/apache/druid/pull/11309

Fixes #7374

### Description

<!--
#### Fixed the bug ...
#### Renamed the class ...
#### Added a forbidden-apis entry ...

In each section, please describe design decisions made, including:
-->
- Choice of algorithms

This PR avoids the more complicated design from #7374 to address the use case of a cluster setup with the total segment size on local disk smaller than the page cache usable in the RAM by adopting a simpler design to read the index files of all segments for all data sources in a host blindly into null output stream to force OS to load the segment files into page cache during historical process bootstrap and on new segment download after bootstrap. Other setups with a smaller RAM to disk ratio are left to undefined behavior (won't crash but just not the best performance as the intention of the PR).

When the total segment size on local disk is larger than the page cache usable in the RAM, a lot of complications will happen and many of them are out of application's control so this PR tries to avoid this use case:
1) Page cache management is at the discretion of operating system so the OS may evict any existing segments already in page cache based on whatever policy it holds (LRU, LFU, etc.). From the application perspective, we can only assume any segment may be evicted when the page cache is full.
2) If we make it configurable to load only certain data sources into page cache, let's say the host is hosting data source X and Y and only X is configured to load into page cache, unless data source Y is completely not queried, we can't prevent Y from polluting the page cache used by X because when Y is queried, the portion of the bytes needed to complete the query in the segment index file will be mmaped and has to be loaded into page cache by OS and some segments of X in the page cache will have to be evicted first if the page cache is full. A better design to address different data source's need in my opinion is to configure different server pools for X and Y where for a latency sensitive data source X, put it in a cluster of 1 to 1 mapping of available page cache RAM to segment size and enable this feature; for a non latency sensitive data source Y, put it in another cluster of historical nodes of smaller page cache RAM to disk ratio and disable this feature so on demand page
in and page out during mmap is performed. Although the user can still choose to enable this feature for Y but it just won't be as effective.

This PR trades availability off performance, so the whole loading segments into page cache is done in a thread pool asynchronously to not delay historical process startup and to not impact data readiness for query ETA when available for download.

<!--

- Behavioral aspects. What configuration values are acceptable? How are corner cases and error conditions handled, such as when there are insufficient resources?

- Class organization and design (how the logic is split between classes, inheritance, composition, design patterns)
- Method organization and design (how the logic is split between methods, parameters and return types)
- Naming (class, method, API, configuration, HTTP endpoint, names of emitted metrics)

It's good to describe an alternative design (or mention an alternative name) for every design (or naming) decision point and compare the alternatives with the designs that you've implemented (or the names you've chosen) to highlight the advantages of the chosen designs and names. -->

<!-- Some of the aspects mentioned above may be omitted for simple and small changes.

<hr>

##### Key changed/added classes in this PR
* `MyFoo`
* `OurBar`
* `TheirBaz`

<hr>

-->

This PR has:
- [x] been self-reviewed.
- [ ] using the [concurrency checklist](https://github.com/apache/druid/blob/master/dev/code-review/concurrency.md) (Remove this item if the PR doesn't have any relation to concurrency.)
- [x] added documentation for new or modified features or behaviors.
- [x] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
- [x] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
- [ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for [code coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md) is met.
- [ ] added integration tests.
- [x] been tested in a test Druid cluster.

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org