|
@@ -36,12 +36,24 @@ number of workers is. This can be tested by progressively increasing the
|
|
|
number of workers until either I/O or CPU is saturated on the cluster.
|
|
|
|
|
|
[float]
|
|
|
-=== Increase the refresh interval
|
|
|
-
|
|
|
-The default <<dynamic-index-settings,`index.refresh_interval`>> is `1s`, which
|
|
|
-forces Elasticsearch to create a new segment every second.
|
|
|
-Increasing this value (to say, `30s`) will allow larger segments to flush and
|
|
|
-decreases future merge pressure.
|
|
|
+=== Unset or increase the refresh interval
|
|
|
+
|
|
|
+The operation that consists of making changes visible to search - called a
|
|
|
+<<indices-refresh,refresh>> - is costly, and calling it often while there is
|
|
|
+ongoing indexing activity can hurt indexing speed.
|
|
|
+
|
|
|
+By default, Elasticsearch runs this operation every second, but only on
|
|
|
+indices that have received one search request or more in the last 30 seconds.
|
|
|
+This is the optimal configuration if you have no or very little search traffic
|
|
|
+(e.g. less than one search request every 5 minutes) and want to optimize for
|
|
|
+indexing speed.
|
|
|
+
|
|
|
+On the other hand, if your index experiences regular search requests, this
|
|
|
+default behavior means that Elasticsearch will refresh your index every 1
|
|
|
+second. If you can afford to increase the amount of time between when a document
|
|
|
+gets indexed and when it becomes visible, increasing the
|
|
|
+<<dynamic-index-settings,`index.refresh_interval`>> to a larger value, e.g.
|
|
|
+`30s`, might help improve indexing speed.
|
|
|
|
|
|
[float]
|
|
|
=== Disable refresh and replicas for initial loads
|