Edited 510_Deployment/45_dont_touch.asciidoc with Atlas code editor

Author: skalapurakkel

510_Deployment/45_dont_touch.asciidoc

@@ -1,10 +1,8 @@
 
-=== Don't touch these settings!
+=== Don't Touch These Settings!
 
 There are a few hotspots in Elasticsearch that people just can't seem to avoid
-tweaking. ((("deployment", "settings to leave unaltered"))) We understand:  knobs just beg to be turned.
-
-But of all the knobs to turn, these you should _really_ leave alone.  They are
+tweaking. ((("deployment", "settings to leave unaltered"))) We understand:  knobs just beg to be turned. But of all the knobs to turn, these you should _really_ leave alone. They are
 often abused and will contribute to terrible stability or terrible performance.
 Or both.
 
@@ -27,10 +25,10 @@ like Elasticsearch.  The official recommendation is to use CMS.
 There is a newer GC called the Garbage First GC (G1GC). ((("Garbage First GC (G1GC)"))) This newer GC is designed
 to minimize pausing even more than CMS, and operate on large heaps.  It works
 by dividing the heap into regions and predicting which regions contain the most
-reclaimable space.  By collecting those regions first ("garbage first"), it can
+reclaimable space.  By collecting those regions first (_garbage first_), it can
 minimize pauses and operate on very large heaps.
 
-Sounds great!  Unfortunately, G1GC is still new and fresh bugs are found routinely.
+Sounds great!  Unfortunately, G1GC is still new, and fresh bugs are found routinely.
 These bugs are usually of the segfault variety, and will cause hard crashes.
 The Lucene test suite is brutal on GC algorithms, and it seems that G1GC hasn't
 had the kinks worked out yet.
@@ -46,37 +44,36 @@ a lot? More threads!  Node idling 95% of the time?  More threads!
 
 The default threadpool settings in Elasticsearch are very sensible.  For all
 threadpools (except `search`) the threadcount is set to the number of CPU cores.
-If you have 8 cores, you can only be running 8 threads simultaneously.  It makes
-sense to only assign 8 threads to any particular threadpool.
+If you have eight cores, you can be running only eight threads simultaneously.  It makes
+sense to assign only eight threads to any particular threadpool.
 
 Search gets a larger threadpool, and is configured to `# cores * 3`. 
 
 You might argue that some threads can block (such as on a disk I/O operation), 
-which is why you need more threads.  This is not actually not a problem in Elasticsearch:
-much of the disk IO is handled by threads managed by Lucene, not Elasticsearch.
+which is why you need more threads.  This is not a problem in Elasticsearch:
+much of the disk I/O is handled by threads managed by Lucene, not Elasticsearch.
 
 Furthermore, threadpools cooperate by passing work between each other.  You don't
 need to worry about a networking thread blocking because it is waiting on a disk
 write.  The networking thread will have long since handed off that work unit to
 another threadpool and gotten back to networking.
 
-Finally, the compute capacity of your process is finite.  More threads just forces
-the processor to switch thread contexts.  A processor can only run one thread
+Finally, the compute capacity of your process is finite.  Having more threads just forces
+the processor to switch thread contexts.  A processor can run only one thread
 at a time, so when it needs to switch to a different thread, it stores the current
-state (registers, etc) and loads another thread.  If you are lucky, the switch
+state (registers, and so forth) and loads another thread.  If you are lucky, the switch
 will happen on the same core.  If you are unlucky, the switch may migrate to a
-different core and require transport on inter-core communication bus.
+different core and require transport on an inter-core communication bus.
 
-This context switching eats up cycles simply doing administrative housekeeping
--- estimates can peg it as high as 30μs on modern CPUs.  So unless the thread
+This context switching eats up cycles simply by doing administrative housekeeping; estimates can peg it as high as 30μs on modern CPUs.  So unless the thread
 will be blocked for longer than 30μs, it is highly likely that that time would
 have been better spent just processing and finishing early.
 
-People routinely set threadpools to silly values.  On 8 core machines, we have
-run across configs with 60, 100 or even 1000 threads.  These settings will simply
+People routinely set threadpools to silly values.  On eight core machines, we have
+run across configs with 60, 100, or even 1000 threads.  These settings will simply
 thrash the CPU more than getting real work done.
 
-So. Next time you want to tweak a threadpool...please don't.  And if you
+So. Next time you want to tweak a threadpool, please don't.  And if you
 _absolutely cannot resist_, please keep your core count in mind and perhaps set
 the count to double.  More than that is just a waste.