Skip to content

Commit 61ecfa1

Browse files
pengqiuyuanmedcl
authored andcommitted
chapter46_part2: /510_Deployment/20_hardware.asciidoc
小括号前后去掉空格
1 parent 277cdda commit 61ecfa1

File tree

1 file changed

+9
-11
lines changed

1 file changed

+9
-11
lines changed

510_Deployment/20_hardware.asciidoc

Lines changed: 9 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,35 +1,33 @@
11
[[hardware]]
22
=== 硬件
33

4-
按照正常的流程,你可能已经 ((("deployment", "hardware")))((("hardware"))) 在自己的笔记本电脑或集群上使用了 Elasticsearch 。
4+
按照正常的流程,你可能已经((("deployment", "hardware")))((("hardware")))在自己的笔记本电脑或集群上使用了 Elasticsearch 。
55
但是当要部署 Elasticsearch 到生产环境时,有一些建议是你需要考虑的。这里没有什么必须要遵守的准则,Elasticsearch 被用于在众多的机器上处理各种任务。基于我们在生产环境使用 Elasticsearch 集群的经验,可以为你提供一个好的起点。
66

77
==== 内存
88

9-
如果有一种资源是最先被耗尽的,它可能是内存。 ((("hardware", "memory")))((("memory")))
10-
排序和聚合都很耗内存,所以有足够的堆空间来应付它们是很重要的。 ((("heap"))) 即使堆空间是比较小的时候,
9+
如果有一种资源是最先被耗尽的,它可能是内存。((("hardware", "memory")))((("memory")))排序和聚合都很耗内存,所以有足够的堆空间来应付它们是很重要的。((("heap")))即使堆空间是比较小的时候,
1110
也能为操作系统文件缓存提供额外的内存。因为 Lucene 使用的许多数据结构是基于磁盘的格式, Elasticsearch 利用操作系统缓存能产生很大效果。
1211

13-
64 GB 内存的机器是非常理想的, 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反 (你最终需要很多很多的小机器), 大于64 GB的机器也会有问题,
12+
64 GB 内存的机器是非常理想的, 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反(你最终需要很多很多的小机器), 大于64 GB的机器也会有问题,
1413
我们将在 <<heap-sizing>> 中讨论。
1514

1615
==== CPUs
1716

18-
大多数 Elasticsearch 部署往往对CPU要求很小。因此, ((("CPUs (central processing units)")))((("hardware", "CPUs")))
19-
确切的处理器安装事项少于其他资源。你应该选择具有多个内核的现代处理器,常见的集群使用两到八个核的机器。
17+
大多数 Elasticsearch 部署往往对CPU要求很小。因此,((("CPUs (central processing units)")))((("hardware", "CPUs")))确切的处理器安装事项少于其他资源。你应该选择具有多个内核的现代处理器,常见的集群使用两到八个核的机器。
2018

2119
如果你要在更快的CPUs和更多的核心之间选择,选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。
2220

2321
==== 硬盘
2422

25-
硬盘对所有的集群都很重要, ((("disks")))((("hardware", "disks"))) 对高度索引的集群更是加倍重要
23+
硬盘对所有的集群都很重要,((("disks")))((("hardware", "disks")))对高度索引的集群更是加倍重要
2624
(例如那些存储日志数据的)。硬盘是服务器上最慢的子系统,这意味着那些写入量很大的集群很容易让硬盘饱和,使得它成为集群的瓶颈。
2725

2826
如果你负担得起 SSD ,它将远远超出任何旋转媒介(注:机械硬盘,磁带等)。 基于 SSD 的节点,查询和索引性能都有提升。如果你负担得起, SSD 是一个好的选择。
2927

3028
.检查你的 I/O 调度程序
3129
****
32-
如果你正在使用 SSDs ,确保你的系统 I/O 调度程序是 ((("I/O scheduler"))) 配置正确的。
30+
如果你正在使用 SSDs ,确保你的系统 I/O 调度程序是((("I/O scheduler")))配置正确的。
3331
当你向硬盘写数据,I/O 调度程序决定何时把数据
3432
_实际_ 发送到硬盘。大多数默认 *nix 发行版下的调度程序都叫做 `cfq` (完全公平队列).
3533
@@ -42,7 +40,7 @@ _实际_ 发送到硬盘。大多数默认 *nix 发行版下的调度程序都
4240
这个简单的更改可以带来显著的影响。仅仅是使用正确的调度程序,我们看到了500倍的写入能力提升。
4341
****
4442

45-
如果你使用旋转媒介,尝试获取尽可能快的硬盘 (高性能服务器硬盘, 15k RPM 驱动器).
43+
如果你使用旋转媒介,尝试获取尽可能快的硬盘(高性能服务器硬盘, 15k RPM 驱动器).
4644

4745
使用 RAID 0 是提高硬盘速度的有效途径,对旋转硬盘和 SSD 来说都是如此。没有必要使用镜像或其它 RAID 变体,因为高可用已经通过 replicas 内建于 Elasticsearch 之中。
4846

@@ -51,7 +49,7 @@ _实际_ 发送到硬盘。大多数默认 *nix 发行版下的调度程序都
5149

5250
==== 网络
5351

54-
快速可靠的网络显然对分布式系统的性能是很重要的 ((("hardware", "network")))((("network")))
52+
快速可靠的网络显然对分布式系统的性能是很重要的((("hardware", "network")))((("network")))。
5553
低延时能帮助确保节点间能容易的通讯,大带宽能帮助分片移动和恢复。现代数据中心网络 (1 GbE, 10 GbE) 对绝大多数集群都是足够的。
5654

5755
即使数据中心们近在咫尺,也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。
@@ -63,7 +61,7 @@ Elasticsearch 假定所有节点都是平等的--并不会因为有一半的节
6361

6462
==== 一般注意事项
6563

66-
获取真正的巨型机器在今天是可能的:((("hardware", "general considerations"))) 成百 GB 的 RAM 和 几十个 CPU 核心。
64+
获取真正的巨型机器在今天是可能的:((("hardware", "general considerations")))成百 GB 的 RAM 和 几十个 CPU 核心。
6765
反之,在云平台上串联起成千的小虚拟机也是可能的,例如 EC2。哪条道路是最好的?
6866

6967
通常,选择中到大型机器更好。避免使用小型机器,

0 commit comments

Comments
 (0)