Skip to content

Commit a0e41e3

Browse files
committed
Tech review comment fixes
Signed-off-by: David Zane <davizane@amazon.com>
1 parent 2570ac4 commit a0e41e3

2 files changed

Lines changed: 6 additions & 6 deletions

File tree

_tuning-your-cluster/availability-and-recovery/workload-management/wlm-feature-overview.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ Then restart your cluster. For more information, see [Installing plugins]({{site
2929

3030
## Workload groups
3131

32-
A _workload group_ is a logical grouping of tasks with defined resource limits. System administrators can dynamically manage workload groups using the Workload Management APIs. These workload groups can be used to create search requests with resource limits. You can also define group-specific settings, such as timeouts and concurrency limits, that are applied automatically to every request routed to the group. For more information, see [Workload groups]({{site.url}}{{site.baseurl}}/tuning-your-cluster/availability-and-recovery/workload-management/workload-groups/) and [Workload group settings]({{site.url}}{{site.baseurl}}/tuning-your-cluster/availability-and-recovery/workload-management/workload-group-settings/).
32+
A _workload group_ is a logical grouping of tasks with defined resource limits. System administrators can dynamically manage workload groups using the Workload Management APIs. These workload groups can be used to create search requests with resource limits. You can also define group-specific settings that are applied automatically to every request routed to the group. For more information, see [Workload groups]({{site.url}}{{site.baseurl}}/tuning-your-cluster/availability-and-recovery/workload-management/workload-groups/) and [Workload group settings]({{site.url}}{{site.baseurl}}/tuning-your-cluster/availability-and-recovery/workload-management/workload-group-settings/).
3333

3434
The following example request adds a workload group named `analytics`:
3535

_tuning-your-cluster/availability-and-recovery/workload-management/workload-group-settings.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@ OpenSearch behavior is normally controlled by cluster-wide defaults and per-requ
1818

1919
- **Tenant-specific guardrails**: Apply stricter limits to noisy or untrusted tenants while keeping generous defaults for others, all without touching cluster settings.
2020
- **No client cooperation required**: Limits travel with the workload group, so they apply to every request routed to the group regardless of which client sent it.
21-
- **Optional override of request parameters**: A workload group can be configured to take precedence over aggressive request-level values, protecting the cluster from runaway queries without rejecting them outright.
21+
- **Optional override of request parameters**: A workload group can be configured to take precedence over lenient request-level values, protecting the cluster from runaway queries without rejecting them outright.
2222
- **Centralized policy**: All guardrails for a tenant live in one place alongside the group's `resource_limits` and `resiliency_mode`.
2323

2424
## Supported settings
@@ -29,11 +29,11 @@ Each workload group setting accepts the same value range as the underlying reque
2929

3030
| Setting | Type | Description | Equivalent request parameter | Equivalent cluster setting |
3131
| :--- | :--- | :--- | :--- | :--- |
32-
| `search.default_search_timeout` | Time | Hard upper bound on search execution time. Applied only when the request does not already specify a `timeout`. Accepts a [time unit]({{site.url}}{{site.baseurl}}/api-reference/common-parameters/#time-units) value, for example, `30s` or `1m`. | [`timeout`]({{site.url}}{{site.baseurl}}/api-reference/search-apis/search/) | [`search.default_search_timeout`]({{site.url}}{{site.baseurl}}/install-and-configure/configuring-opensearch/search-settings/) |
33-
| `search.cancel_after_time_interval` | Time | Time after which a search request is automatically canceled. Helps prevent runaway queries from consuming resources indefinitely. Accepts a time unit value. | [`cancel_after_time_interval`]({{site.url}}{{site.baseurl}}/api-reference/search-apis/search/) | [`search.cancel_after_time_interval`]({{site.url}}{{site.baseurl}}/install-and-configure/configuring-opensearch/search-settings/) |
32+
| `search.default_search_timeout` | Time | Per-shard limit on query execution. When a shard exceeds the limit, it stops collecting hits and returns its current results to the coordinating node, which may produce partial results. | [`timeout`]({{site.url}}{{site.baseurl}}/api-reference/search-apis/search/) | [`search.default_search_timeout`]({{site.url}}{{site.baseurl}}/install-and-configure/configuring-opensearch/search-settings/) |
33+
| `search.cancel_after_time_interval` | Time | Coordinating-node-level deadline for the entire search request. When the interval is reached, the request and all associated tasks are canceled and the client receives an error rather than partial results. | [`cancel_after_time_interval`]({{site.url}}{{site.baseurl}}/api-reference/search-apis/search/) | [`search.cancel_after_time_interval`]({{site.url}}{{site.baseurl}}/install-and-configure/configuring-opensearch/search-settings/) |
3434
| `search.max_concurrent_shard_requests` | Integer | Maximum number of concurrent shard-level requests a single search may issue per node. Limits search fan-out. | [`max_concurrent_shard_requests`]({{site.url}}{{site.baseurl}}/api-reference/search-apis/search/) | -- |
35-
| `search.batched_reduce_size` | Integer | Number of shard results reduced at a time on the coordinating node. Lower values reduce coordinator heap pressure for high–shard-count searches. | [`batched_reduce_size`]({{site.url}}{{site.baseurl}}/api-reference/search-apis/search/) | -- |
36-
| `search.max_buckets` | Integer | Maximum number of aggregation buckets a request in this group may produce. Guards against excessive memory use from wide aggregations. When set, this value always takes precedence over the cluster-wide `search.max_buckets` setting. | -- | [`search.max_buckets`]({{site.url}}{{site.baseurl}}/install-and-configure/configuring-opensearch/search-settings/) |
35+
| `search.batched_reduce_size` | Integer | Number of shard results combined into one batch on the coordinating node before the final reduce. Lower values reduce coordinator memory usage when a search spans many shards. | [`batched_reduce_size`]({{site.url}}{{site.baseurl}}/api-reference/search-apis/search/) | -- |
36+
| `search.max_buckets` | Integer | Maximum number of aggregation buckets allowed in a single response. Guards against excessive memory use from large aggregations. | -- | [`search.max_buckets`]({{site.url}}{{site.baseurl}}/install-and-configure/configuring-opensearch/search-settings/) |
3737
| `override_request_values` | Boolean | Whether the workload group's settings take precedence over values supplied on the request. Default is `false`. See [Precedence](#precedence). | -- | -- |
3838

3939
### Precedence

0 commit comments

Comments
 (0)