Dynamic shard sizing based on search nodes operating system memory#24372
Dynamic shard sizing based on search nodes operating system memory#24372patrickmann merged 6 commits intomasterfrom
Conversation
|
Codex noticed this: |
# Conflicts: # graylog2-server/src/main/java/org/graylog2/datatiering/rotation/DataTierRotation.java # graylog2-server/src/main/java/org/graylog2/indexer/rotation/strategies/TimeBasedSizeOptimizingStrategy.java # graylog2-server/src/test/java/org/graylog2/indexer/rotation/strategies/TimeBasedSizeOptimizingRotationAndRetentionTest.java
...og2-server/src/main/java/org/graylog2/indexer/rotation/tso/TimeSizeOptimizingCalculator.java
Show resolved
Hide resolved
|
@AntonEbel @patrickmann Is the memory calculation container aware? E.g. when running OpenSearch as a pod in Kubernetes and setting memory limits? |
|
@boosty We currently use the following value |
|
@AntonEbel Thanks for the quick feedback! That is a very important piece of information. I think it's not uncommon to deploy DataNode (or raw OpenSearch) as containers these days. The new official Graylog Helm chart will probably accelerate this. @tellistone pinging you for awareness. |
Description
This PR implements dynamic shard sizing for the index rotation.
TIME_SIZE_OPTIMIZING_ROTATION_MIN_SHARD_SIZEandTIME_SIZE_OPTIMIZING_ROTATION_MAX_SHARD_SIZEno longer have default values. If either of these configuration fields is not set, dynamic shard sizing is enabled. This feature uses the operating system memory of Opensearch/Elasticsearch nodes with thedatarole to calculate the maximum index shard size. For this purpose, the node with the smallest memory is used.Motivation and Context
closes #23947 (Pitch)
How Has This Been Tested?
Types of changes
/prd Graylog2/graylog-plugin-enterprise#12643