Edited 510_Deployment/50_heap.asciidoc with Atlas code editor

Author: troutman_margaret@yahoo.com

510_Deployment/50_heap.asciidoc

@@ -1,11 +1,11 @@
 [[heap-sizing]]
 === Heap: Sizing and Swapping
 
-The default installation of Elasticsearch is configured with a 1gb heap. ((("deployment", "heap, sizing and swapping"))) For
+The default installation of Elasticsearch is configured with a 1gb heap. ((("deployment", "heap, sizing and swapping")))((("heap", "sizing and setting"))) For
 just about every deployment, this number is far too small.  If you are using the
 default heap values, your cluster is probably configured incorrectly.
 
-There are two ways to change the heap size in Elasticsearch.((("heap size, setting")))  The easiest is to
+There are two ways to change the heap size in Elasticsearch.  The easiest is to
 set an environment variable called `ES_HEAP_SIZE`.((("ES_HEAP_SIZE environment variable")))  When the server process
 starts, it will read this environment variable and set the heap accordingly.
 As an example, you can set it via the command line with:
@@ -30,9 +30,9 @@ explicit `-Xmx` and `-Xms` values.
 
 ==== Give half your memory to Lucene
 
-A common problem is configuring a heap that is _too_ large.  You have a 64gb
+A common problem is configuring a heap that is _too_ large. ((("heap", "sizing and setting", "giving half your memory to Lucene"))) You have a 64gb
 machine...and by golly, you want to give Elasticsearch all 64gb of memory.  More
-is better!((("memory", "allocating for Lucene")))
+is better!
 
 Heap is definitely important to Elasticsearch.  It is used by many in-memory data
 structures to provide fast operation.  But with that said, there is another major
@@ -53,7 +53,7 @@ gobble up whatever is leftover.
 
 [[compressed_oops]]
 ==== Don't cross 32gb!
-There is another reason to not allocate enormous heaps to Elasticsearch. As it turns((("32gb Heap boundary")))
+There is another reason to not allocate enormous heaps to Elasticsearch. As it turns((("heap", "sizing and setting", "32gb heap boundary")))((("32gb Heap boundary")))
 out, the JVM uses a trick to compress object pointers when heaps are less than
 ~32gb.
 
@@ -112,7 +112,7 @@ to the same physical machine (since this would remove the benefits of replica HA
 
 ==== Swapping is the death of performance
 
-It should be obvious,((("memory", "swapping as the death of performance")))((("swapping, the death of performance"))) but it bears spelling out clearly: swapping main memory
+It should be obvious,((("heap", "sizing and setting", "swapping, death of performance")))((("memory", "swapping as the death of performance")))((("swapping, the death of performance"))) but it bears spelling out clearly: swapping main memory
 to disk will _crush_ server performance.  Think about it...an in-memory operation
 is one that needs to execute quickly.