chapter46_part2: /510_Deployment/45_dont_touch.asciidoc

修改一些问题 @biyuhao 🙏

Author: pengqiuyuan

510_Deployment/45_dont_touch.asciidoc

@@ -1,7 +1,7 @@
 
 === 不要触碰这些配置！
 
-在 Elasticsearch 中有一些热点，人们可能不可避免的会碰到。我们理解的，所有的调整就是为了优化，但是这些调整，你真的不需要理会它。因为它们经常会被乱用，从而造成系统的不稳定或者糟糕的性能，甚至两者都有可能。
+在 Elasticsearch 中有一些热点，人们可能不可避免的会碰到。((("deployment", "settings to leave unaltered"))) 我们理解的，所有的调整就是为了优化，但是这些调整，你真的不需要理会它。因为它们经常会被乱用，从而造成系统的不稳定或者糟糕的性能，甚至两者都有可能。
 
 ==== 垃圾回收器
 
@@ -16,35 +16,34 @@ Elasticsearch 默认的垃圾回收器（ GC ）是 CMS。((("Concurrent-Mark an
 尽管有这些缺点，它还是目前对于像 Elasticsearch 这样低延迟需求软件的最佳垃圾回收器。官方建议使用 CMS。
 
 现在有一款新的垃圾回收器，叫 G1 垃圾回收器（ G1GC ）。((("Garbage First GC (G1GC)"))) 这款新的 GC 被设计，旨在比 CMS 更小的暂停时间，以及对大内存的处理能力。
-它的原理是把内存分成许多区域，并且预测哪些区域最有可能需要回收内存。（ _G1GC_ ）通过收集这些区域，产生更小的暂停时间，从而能应对更大的内存。
+它的原理是把内存分成许多区域，并且预测哪些区域最有可能需要回收内存。通过优先收集这些区域（ _garbage first_ ），产生更小的暂停时间，从而能应对更大的内存。
 
-听起来很棒！遗憾的是，G1GC 还是太新了，经常发现新的 bugs。这些错误通常是分段错误的类型，便造成硬盘的崩溃。
-Lucene 的测试套件对 GC 是很严格的，看起来这些缺陷 G1GC 并没有很好地解决。
+听起来很棒！遗憾的是，G1GC 还是太新了，经常发现新的 bugs。这些错误通常是段（ segfault ）类型，便造成硬盘的崩溃。
+Lucene 的测试套件对垃圾回收算法要求严格，看起来这些缺陷 G1GC 并没有很好地解决。
 
 我们很希望在将来某一天推荐使用 G1GC，但是对于现在，它还不能足够稳定的满足 Elasticsearch 和 Lucene 的要求。
 
 ==== 线程池
 
-许多人 _喜欢_ 调整线程池。((("threadpools"))) 无论什么原因，人们好像都无法抵挡的想增加线程数。索引太多了？增加线程！搜索太多了？增加线程！节点空闲率低于 95％？增加线程！
+许多人 _喜欢_ 调整线程池。((("threadpools"))) 无论什么原因，人们都对增加线程数无法抵抗。索引太多了？增加线程！搜索太多了？增加线程！节点空闲率低于 95％？增加线程！
 
 Elasticsearch 默认的线程设置已经是很合理的了。对于所有的线程池（除了 `搜索` ），线程个数是根据 CPU 核心数设置的。
 如果你有 8 个核，你可以同时运行的只有 8 个线程，只分配 8 个线程给任何特定的线程池是有道理的。
 
 搜索线程池设置的大一点，配置为 `int（（ 核心数 ＊ 3 ）／ 2 ）＋ 1` 。
 
-你可能会认为某些线程可能会阻塞（如磁盘上的 I／O 操作），所以你才想加大线程的。这并不是 Elasticsearch 的一个问题：
-因为大多数 I／O 的操作是由 Lucene 线程管理的，而不是 Elasticsearch。
+你可能会认为某些线程可能会阻塞（如磁盘上的 I／O 操作），所以你才想加大线程的。对于 Elasticsearch 来说这并不是一个问题：因为大多数 I／O 的操作是由 Lucene 线程管理的，而不是 Elasticsearch。
 
 此外，线程池通过传递彼此之间的工作配合。你不必再因为它正在等待磁盘写操作而担心网络线程阻塞，
 因为网络线程早已把这个工作交给另外的线程池，并且网络进行了响应。
 
-最后，你的处理器的计算容量是有限的，拥有更多的线程会导致你的处理器频繁切换线程上下文。
+最后，你的处理器的计算能力是有限的，拥有更多的线程会导致你的处理器频繁切换线程上下文。
 一个处理器同时只能运行一个线程。所以当它需要切换到其它不同的线程的时候，它会存储当前的状态（寄存器等等），然后加载另外一个线程。
 如果幸运的话，这个切换发生在同一个核心，如果不幸的话，这个切换可能发生在不同的核心，这就需要在内核间总线上进行传输。
 
-这个上下文的切换，会循环的带来管理调度开销；在现代的 CPUs 上，开销估计高达 30 μs。也就是说线程会被堵塞超过 30 μs，如果这个时间用于线程的运行，极有可能早就结束了。
+这个上下文的切换，会给 CPU 时钟周期带来管理调度的开销；在现代的 CPUs 上，开销估计高达 30 μs。也就是说线程会被堵塞超过 30 μs，如果这个时间用于线程的运行，极有可能早就结束了。
 
-人们经常稀里糊涂的设置线程池的值。8 个核的 CUP，我们遇到过有人配了 60、100 甚至 1000 个线程。
+人们经常稀里糊涂的设置线程池的值。8 个核的 CPU，我们遇到过有人配了 60、100 甚至 1000 个线程。
 这些设置只会让 CPU 实际工作效率更低。
 
 所以，下次请不要调整线程池的线程数。如果你真 _想调整_ ，