7
7
==== 内存
8
8
9
9
如果有一种资源是最先被耗尽的,它可能是内存。((("hardware", "memory")))((("memory")))排序和聚合都很耗内存,所以有足够的堆空间来应付它们是很重要的。((("heap")))即使堆空间是比较小的时候,
10
- 也能为操作系统文件缓存提供额外的内存。因为 Lucene 使用的许多数据结构是基于磁盘的格式, Elasticsearch 利用操作系统缓存能产生很大效果。
10
+ 也能为操作系统文件缓存提供额外的内存。因为 Lucene 使用的许多数据结构是基于磁盘的格式,Elasticsearch 利用操作系统缓存能产生很大效果。
11
11
12
- 64 GB 内存的机器是非常理想的, 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反( 你最终需要很多很多的小机器) ,大于64 GB 的机器也会有问题,
12
+ 64 GB 内存的机器是非常理想的, 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反( 你最终需要很多很多的小机器) ,大于64 GB 的机器也会有问题,
13
13
我们将在 <<heap-sizing>> 中讨论。
14
14
15
15
==== CPUs
20
20
21
21
==== 硬盘
22
22
23
- 硬盘对所有的集群都很重要,((("disks")))((("hardware", "disks")))对大量写入的集群更是加倍重要( 例如那些存储日志数据的) 。硬盘是服务器上最慢的子系统,这意味着那些写入量很大的集群很容易让硬盘饱和,使得它成为集群的瓶颈。
23
+ 硬盘对所有的集群都很重要,((("disks")))((("hardware", "disks")))对大量写入的集群更是加倍重要( 例如那些存储日志数据的) 。硬盘是服务器上最慢的子系统,这意味着那些写入量很大的集群很容易让硬盘饱和,使得它成为集群的瓶颈。
24
24
25
- 如果你负担得起 SSD,它将远远超出任何旋转介质( 注:机械硬盘,磁带等) 。 基于 SSD 的节点,查询和索引性能都有提升。如果你负担得起, SSD 是一个好的选择。
25
+ 如果你负担得起 SSD,它将远远超出任何旋转介质( 注:机械硬盘,磁带等) 。 基于 SSD 的节点,查询和索引性能都有提升。如果你负担得起,SSD 是一个好的选择。
26
26
27
27
.检查你的 I/O 调度程序
28
28
****
29
29
如果你正在使用 SSDs,确保你的系统 I/O 调度程序是((("I/O scheduler")))配置正确的。
30
30
当你向硬盘写数据,I/O 调度程序决定何时把数据
31
- _实际_ 发送到硬盘。大多数默认 *nix 发行版下的调度程序都叫做 `cfq` ( 完全公平队列) 。
31
+ _实际_ 发送到硬盘。大多数默认 *nix 发行版下的调度程序都叫做 `cfq`( 完全公平队列) 。
32
32
33
33
调度程序分配 _时间片_ 到每个进程。并且优化这些到硬盘的众多队列的传递。但它是为旋转介质优化的:
34
34
旋转盘片的固有特性意味着它写入数据到基于物理布局的硬盘会更高效。
@@ -39,23 +39,23 @@ _实际_ 发送到硬盘。大多数默认 *nix 发行版下的调度程序都
39
39
这个简单的更改可以带来显著的影响。仅仅是使用正确的调度程序,我们看到了500倍的写入能力提升。
40
40
****
41
41
42
- 如果你使用旋转介质,尝试获取尽可能快的硬盘( 高性能服务器硬盘,15k RPM 驱动器) 。
42
+ 如果你使用旋转介质,尝试获取尽可能快的硬盘( 高性能服务器硬盘,15k RPM 驱动器) 。
43
43
44
44
使用 RAID 0 是提高硬盘速度的有效途径,对机械硬盘和 SSD 来说都是如此。没有必要使用镜像或其它 RAID 变体,因为高可用已经通过 replicas 内建于 Elasticsearch 之中。
45
45
46
- 最后,避免使用网络附加存储 ( NAS) 。人们常声称他们的 NAS 解决方案比本地驱动器更快更可靠。除却这些声称,
47
- 我们从没看到NAS能配得上它的大肆宣传。 NAS 常常很慢,显露出更大的延时和更宽的平均延时方差,而且它是单点故障的。
46
+ 最后,避免使用网络附加存储( NAS) 。人们常声称他们的 NAS 解决方案比本地驱动器更快更可靠。除却这些声称,
47
+ 我们从没看到 NAS 能配得上它的大肆宣传。 NAS 常常很慢,显露出更大的延时和更宽的平均延时方差,而且它是单点故障的。
48
48
49
49
==== 网络
50
50
51
51
快速可靠的网络显然对分布式系统的性能是很重要的((("hardware", "network")))((("network")))。
52
- 低延时能帮助确保节点间能容易的通讯,大带宽能帮助分片移动和恢复。现代数据中心网络( 1 GbE, 10 GbE) 对绝大多数集群都是足够的。
52
+ 低延时能帮助确保节点间能容易的通讯,大带宽能帮助分片移动和恢复。现代数据中心网络( 1 GbE, 10 GbE) 对绝大多数集群都是足够的。
53
53
54
54
即使数据中心们近在咫尺,也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。
55
55
56
56
Elasticsearch 假定所有节点都是平等的--并不会因为有一半的节点在150ms 外的另一数据中心而有所不同。更大的延时会加重分布式系统中的问题而且使得调试和排错更困难。
57
57
58
- 和 NAS 的争论类似,每个人都声称他们的数据中心间的线路都是健壮和低延时的。这是真的--直到它不是时( 网络失败终究是会发生的,你可以相信它) 。
58
+ 和 NAS 的争论类似,每个人都声称他们的数据中心间的线路都是健壮和低延时的。这是真的--直到它不是时( 网络失败终究是会发生的,你可以相信它) 。
59
59
从我们的经验来看,处理跨数据中心集群的麻烦事是根本不值得的。
60
60
61
61
==== 一般注意事项
@@ -66,4 +66,4 @@ Elasticsearch 假定所有节点都是平等的--并不会因为有一半的节
66
66
通常,选择中配或者高配机器更好。避免使用低配机器,
67
67
因为你不会希望去管理拥有上千个节点的集群,而且在这些低配机器上 运行 Elasticsearch 的开销也是显著的。
68
68
69
- 与此同时,避免使用真正的高配机器。它们通常会导致资源使用不均衡( 例如,所有的内存都被使用,但 CPU 没有) 而且在单机上运行多个节点时,会增加逻辑复杂度。
69
+ 与此同时,避免使用真正的高配机器。它们通常会导致资源使用不均衡( 例如,所有的内存都被使用,但 CPU 却没有) 而且在单机上运行多个节点时,会增加逻辑复杂度。
0 commit comments