Elasticsearch资源分配

一、CPUs

大多数 Elasticsearch 部署往往对 CPU 要求不高。因此，相对其它资源，具体配置多少个（CPU）不是那么关键。你应该选择具有多个内核的现代处理器，常见的集群使用两到八个核的机器。 

二、内存

64 GB 内存的机器是非常理想的， 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反（你最终需要很多很多的小机器），大于64 GB 的机器也会有问题，

Elasticsearch 分为两部分，一部分是本身的堆内存，另一部分是lucene使用非堆内存，标准的建议是把 50％ 的可用内存作为 Elasticsearch 的堆内存，保留剩下的 50％留给lucene；如果不需要对分词字符串做聚合计算（例如，不需要 fielddata ）可以考虑降低堆内存。堆内存越小，Elasticsearch（更快的 GC）和 Lucene（更多的内存用于缓存）的性能越好。

 由于JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术，所以分配给 Elasticsearch的内存不要超过 临界值 ~32GB，设置堆内存为 31GB 是一个安全的选择。

三、存储分配

无需使用镜像或其它 RAID 变体，因为高可用已经通过 replicas 建于 Elasticsearch 之中；

避免使用网络附加存储（NAS），尽可能使用SSD， 基于 SSD 的节点，查询和索引性能都有提升。ES 服务存储容量的主要因素如下：

副本数量：副本有利于增加数据的可靠性，但同时会增加存储成本。默认和建议的副本数量为1，对于部分可以承受异常情况导致数据丢失的场景，可考虑设置副本数量为0。

数据膨胀：除原始数据外，ES 需要存储索引、列存数据等，在应用编码压缩等技术后，一般膨胀10%。

内部任务开销：ES 占用约20%的磁盘空间，用于 segment 合并、ES Translog、日志等。

操作系统预留：Linux 操作系统默认为 root 用户预留5%的磁盘空间，用于关键流程处理、系统恢复、防止磁盘碎片化问题等。

因此，数据在 ES 中占用的实际空间可通过下面公式估算：

实际空间 = 源数据 × (1 + 副本数量) × (1 + 数据膨胀) / (1 - 内部任务开销) / (1 - 操作系统预留)≈ 源数据 × (1 + 副本数量) × 1.45

为保证服务的稳定运行，建议至少预留15%的存储空间，因此建议申请的存储容量为：

存储容量 = 源数据 × (1 + 副本数量) × 1.45 × （1 + 预留空间）

≈ 源数据 × (1 + 副本数量) × 1.67

四、分片数量评估

每个 ES 索引被分为多个分片，数据按哈希算法打散到不同的分片中。由于索引分片的数量影响读写性能、故障恢复速度，且通常无法轻松更改，需要提前考虑。这里给出配置分片数量的一些常用建议：

建议单个分片大小保持在10GB - 50GB之间，您可以据此初步确定 Index 的分片数量。分片不宜过大或过小：过大可能使 ES 的故障恢复速度变慢；过小可能导致非常多的分片，但因为每个分片使用一些数量的 CPU 和内存，从而导致读写性能、内存不足等问题。

当分片数量超过数据节点数量时，建议分片数量接近数据节点的整数倍，方便分片在所有数据节点均匀分布。

五、实例类型选择及测试

建议您至少选择3个节点，避免 ES 实例出现脑裂问题，保证 ES 实例具有较高的节点故障容错能力。

建议选择高规格的节点，避免大量低规格节点，这对大实例的性能、稳定性等有较大好处。例如，若您有40核160GB内存5TB存储容量需求，建议选择8核32GB内存1TB × 5节点的实例。同理，当您需要对实例扩容时，建议优先进行纵向扩容，把节点扩容到8核32GB或16核64GB的规格，然后再考虑横向扩容增加节点个数。

使用真实数据进行测试，通过观察 CPU 使用率、写入指标（性能、拒绝率）、查询指标（QPS、拒绝率）等监控信息，进一步确认实例类型是否合适。另外，建议针对上述监控信息配置告警，方便在线上使用时，及时发现资源不足等问题。

参考：

https://www.elastic.co/guide/cn/elasticsearch/guide/current/hardware.htmlhttps://www.elastic.co/guide/cn/elasticsearch/guide/current/hardware.html

https://cloud.tencent.com/document/product/845/19551https://cloud.tencent.com/document/product/845/19551