Elasticsearch(ES) 配置建议

Elasticsearch的内存建议设置为32GB以下,‌主要是因为Java虚拟机(‌JVM)‌在内存小于32G时会采用内存对象指针压缩技术,‌以提高内存使用效率。‌这种技术通过压缩对象指针,‌使得32位的指针可以引用40亿个对象,‌而不是40亿个字节,‌从而在堆内存达到32G时,‌仍然能够使用32bit的指针表示。‌然而,‌一旦内存超过这个界限,‌指针将切换到普通对象的指针,‌这将导致每个对象的指针变长,‌从而浪费更多的CPU和内存带宽,‌降低性能。‌此外,‌当JVM的内存设置为32GB以上时,‌实际使用的内存效果会下降,‌因为压缩下的对象会比未压缩的要小一些,‌正常是20-30%的差异。‌因此,‌为了效率和性能的考虑,‌建议将Elasticsearch的内存设置在32GB以下。

尽管内存充足,也应避免超过32GB的使用,以免浪费资源、降低CPU效率,并增加垃圾回收(GC)的负担。

推荐配置:

|-----|-----------|-------------|-------------------------|
| 日志类 | 特点 | 磁盘 | 集群节点数 |
| 搜索类 | 写入较少,查询频繁 | 单个分片不超过20G | 1:16 (内存:节点要存储的数据) |
| 日志类 | 写入频繁,查询较少 | 单个分片不要大于50G | 1:48-1:96 (内存:节点要存储的数据) |
| 冷节点 | 写入较少,查询较少 | | 1:96 |

对于数据量较小(100GB以下)的index

  • 往往写入压力查询压力相对较低,一般设置3~5个shard,numberofreplicas设置为1即可(也就是一主一从,共两副本)。

对于数据量较大(100GB以上)的index:

  • 一般把单个shard的数据量控制在(20GB~50GB)
  • 让index压力分摊至多个节点:可通过下面的参数来强制限定一个节点上该index的shard数量,让shard尽量分配到不同节点上。参数:
  • index.routing.allocation.totalshardsper_node
相关推荐
Elasticsearch1 天前
Kibana 中的 SNMP 拓扑数据:从采集到 Canvas
elasticsearch
大大大大晴天1 天前
Hudi技术内幕:RecordPayload到RecordMerger
大数据
SelectDB2 天前
秒级弹性、最高降本 70%:SelectDB Serverless 如何重塑云数仓资源效率
大数据·后端·云原生
WhoAmI2 天前
MapReduce框架原理解析一:InputFormat
大数据·hadoop
WhoAmI2 天前
MapReduce框架原理解析三:OutputFormat
大数据·hadoop
WhoAmI2 天前
MapReduce框架原理解析二:Shuffle
大数据·hadoop
大大大大晴天3 天前
Hudi技术内幕:Key Generation原理与实践
大数据
Elasticsearch3 天前
3个信号、2个环境变量、0个采集器:使用 Python 和 Elastic 的托管 OTLP 端点实现 OpenTelemetry
elasticsearch
Elasticsearch5 天前
如何通过 Claude Code 来写入 CSV 数据到 Elasticsearch
elasticsearch