honeymoose/OpenSearch
1
0
Fork 0
mirror of https://github.com/honeymoose/OpenSearch.git synced 2025-03-24 17:09:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

don't mention fixed throttling in the docs

Browse Source
This commit is contained in:
Michael McCandless 2015-01-14 10:13:10 -05:00 committed by mikemccand
parent 107099affa
commit def2d34f80
4 changed files with 0 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
docs/reference/cluster/update-settings.asciidoc
View File

@ -183,15 +183,6 @@ due to forced awareness or allocation filtering.
`indices.recovery.max_bytes_per_sec`::
See <<modules-indices>>
[float]
==== Store level throttling
`indices.store.throttle.type`::
See <<index-modules-store>>
`indices.store.throttle.max_bytes_per_sec`::
See <<index-modules-store>>
[float]
[[logger]]
=== Logger

6
docs/reference/index-modules/merge.asciidoc
View File

@ -7,12 +7,6 @@ where the index data is stored, and are immutable up to delete markers.
Segments are, periodically, merged into larger segments to keep the
index size at bay and expunge deletes.
The more segments one has in the Lucene index means slower searches and
more memory used. Segment merging is used to reduce the number of segments,
however merges can be expensive to perform, especially on low IO environments.
Merges can be throttled using <<store-throttling,store level throttling>>.
[float]
[[policy]]
=== Policy

31
docs/reference/index-modules/store.asciidoc
View File

@ -19,37 +19,6 @@ to the fact that there is no need for extra large JVM heaps (with their
own consequences) for storing the index in memory.
[float]
[[store-throttling]]
=== Store Level Throttling
The way Lucene, the IR library elasticsearch uses under the covers,
works is by creating immutable segments (up to deletes) and constantly
merging them (the merge policy settings allow to control how those
merges happen). The merge process happens in an asynchronous manner
without affecting the indexing / search speed. The problem though,
especially on systems with low IO, is that the merge process can be
expensive and affect search / index operation simply by the fact that
the box is now taxed with more IO happening.
The store module allows to have throttling configured for merges (or
all) either on the node level, or on the index level. The node level
throttling will make sure that out of all the shards allocated on that
node, the merge process won't pass the specific setting bytes per
second. It can be set by setting `indices.store.throttle.type` to
`merge`, and setting `indices.store.throttle.max_bytes_per_sec` to
something like `5mb`. The node level settings can be changed dynamically
using the cluster update settings API. The default is disabled (set to `none`),
in favor of <merge,auto throttle in the merge scheduler>.
If specific index level configuration is needed, regardless of the node
level settings, it can be set as well using the
`index.store.throttle.type`, and
`index.store.throttle.max_bytes_per_sec`. The default value for the type
is `node`, meaning it will throttle based on the node level settings and
participate in the global throttling happening. Both settings can be set
using the index update settings API dynamically.
[float]
[[file-system]]
=== File system storage types

13
docs/reference/modules/indices.asciidoc
View File

@ -61,16 +61,3 @@ The following settings can be set to manage the recovery policy:
`indices.recovery.max_bytes_per_sec`::
defaults to `20mb`.
[float]
[[throttling]]
=== Store level throttling
The following settings can be set to control the store throttling:
[horizontal]
`indices.store.throttle.type`::
could be `merge` (default), `none` or `all`. See <<index-modules-store>>.
`indices.store.throttle.max_bytes_per_sec`::
defaults to `20mb`.