W a i k ı ˉ k ı ˉ , H I , U n i t e d S t a t e s Waikīkī, HI, United States Waikıˉkıˉ,HI,UnitedStates
每日语录： “Investing in yourself is the most important investment you’ll ever make in your life.”
引言 引言 引言
如果公司需要对于 ES 进行调优，这个时候你该怎么办呢，不妨提前学习，到时候用到的时候，也可以让大家对你…
如果文章哪里有问题，还望指出。
最后有相关的学习群，有兴趣可以加入。
开始 开始 开始
一、集群规划：避开那些教科书不会写的坑
1. 硬件配置的黄金法则
我们曾因盲目堆配置吃过大亏——128核CPU、1TB内存的豪华机器，性能竟不如32核+256GB的中配集群。关键经验：
- 内存与堆大小：
- JVM堆内存不超过32GB（避免指针压缩失效）
- 总内存 = 堆内存 + 1GB（OS缓存） + 2GB（Lucene预留）
# elasticsearch.yml -Xms30g -Xmx30g - 磁盘选择：
- 优先使用NVMe SSD（随机IOPS需>5万）
- 避免RAID 5/6（写惩罚过高），推荐RAID 10或直连磁盘
- CPU与网络：
- 禁用超线程（实测搜索QPS提升15%）
- 万兆网络必须开启TCP BBR拥塞控制
2. 节点角色的精细化分配
初期我们混用节点角色，导致master节点OOM。现采用分层架构：
# 专用master节点（3/5/7奇数台）
node.master: true
node.data: false
# 数据节点（高配）
node.master: false
node.data: true
search.remote.connect: false
# Coordinating节点（横向扩展）
node.master: false
node.data: false
避坑要点：
- Master节点内存不低于8GB（否则Zen Discovery可能失败）
- Coordinating节点需要高网络带宽
二、索引设计：从分片风暴到性能飞跃
1. 分片大小的科学计算
我们曾因默认5个分片导致400万个小分片，引发集群元数据爆炸。现采用公式：
理想分片数 = 总数据量(GB) / 目标分片大小(GB)
目标分片大小 = 50GB（日志类）~ 100GB（搜索类）
真实案例：
- 原始设计：每日1个索引，5分片1副本 → 每月产生300分片
- 优化后：按周建索引，单索引50分片 → 分片数减少60%
2. 动态模板的智能管理
通过动态模板避免字段爆炸：
PUT _template/business_logs
{
"mappings": {
"dynamic_templates": [
{
"strings_as_keyword": {
"match_mapping_type": "string",
"mapping": {
"type": "keyword",
"ignore_above": 256
}
}
}
]
}
}
该配置将超过256字符的字符串自动丢弃，防止无限制的text分析。
3. 时序数据的冷热分层
PUT logs-2024-08
{
"settings": {
"index.routing.allocation.require.box_type": "hot",
"index.lifecycle.name": "logs_policy"
}
}
# 滚动到冷节点
POST logs-2024-08/_rollover
{
"conditions": { "max_age": "7d" },
"settings": {
"index.routing.allocation.require.box_type": "cold"
}
}
配合ILM策略，热数据用SSD，冷数据迁移到HDD，存储成本降低40%。
三、查询优化：从20秒到200毫秒的魔法
1. 慢查询分析三板斧
- 抓取慢查询：
PUT /_settings { "index.search.slowlog.threshold.query.warn": "10s", "index.search.slowlog.threshold.query.info": "5s" } - 解剖执行计划：
GET /my_index/_search?explain { "query": { ... } } - 强制路由优化：
GET /my_index/_search?preference=_shards:2
2. 聚合查询的加速秘籍
我们曾因一个terms聚合拖垮整个集群：
- 启用doc_values字段：
"properties": { "user_id": { "type": "keyword", "doc_values": true # 默认开启但需确认 } } - 分桶优化：
"aggs": { "popular_items": { "terms": { "field": "product_id", "size": 100, "shard_size": 10000 # 分片级预聚合 } } }
3. 索引预热的黑科技
针对高频查询提前加载：
PUT /hot_index/_settings
{
"index.search.idle.after": "30s",
"index.search.warmup": {
"queries": [
{"term": {"status": "active"}},
{"range": {"timestamp": {"gte": "now-7d/d"}}}
]
}
}
四、运维监控：从救火到预防
- 红色警报线：
- JVM内存使用 > 75%
- 磁盘空间 < 20%
- CPU负载 > 70%持续5分钟
2. 自动化运维脚本
#!/bin/bash
# 自动清理旧索引
cur_date=$(date +%Y.%m.%d)
keep_days=30
indices=$(curl -sXGET http://localhost:9200/_cat/indices?h=index | grep -E "logstash-.*")
for index in $indices; do
index_date=$(echo $index | awk -F '-' '{print $2}')
if [[ "$index_date" < $(date -d "$keep_days days ago" +%Y.%m.%d) ]]; then
curl -XDELETE "http://localhost:9200/$index"
fi
done
3. 灾备恢复策略
- 跨集群复制（CCR）：
PUT /_ccr/follow/logs-follower { "remote_cluster": "backup_cluster", "leader_index": "logs-leader" } - 快照到S3：
# 注册仓库 PUT /_snapshot/my_s3_repository { "type": "s3", "settings": { "bucket": "my-es-backup", "region": "us-west-2" } } # 定时快照 PUT /_slm/policy/nightly-snapshots { "schedule": "0 30 1 * * ?", "name": "<nightly-snap-{now/d}>", "repository": "my_s3_repository" }
五、性能压测：用数据说话
我们使用esrally进行的对比测试：
| 优化项 | QPS提升 | 延迟下降 | 资源消耗下降 |
|---|---|---|---|
| 分片大小调整 | +35% | 42% | 28% |
| JVM参数调优 | +18% | 25% | 15% |
| 查询路由优化 | +52% | 61% | - |
| 冷热数据分离 | - | - | 40% |
测试环境：
- 数据量：5TB
- 节点：6个数据节点（32核/128GB/2TB NVMe）
- 版本：Elasticsearch 8.9.0
六、踩坑启示录
- 不要过度分片：每个分片消耗约2-3GB堆内存
- 避免通配符查询：
*:*会导致全索引扫描 - 慎用fielddata：text类型聚合可能引发内存爆炸
- 定期_forcemerge：合并段文件提升查询性能
POST /my_index/_forcemerge?max_num_segments=1
优化永无止境：Elasticsearch集群如同精密的瑞士手表，每个参数都是相互关联的齿轮。本文的方案来自日均百亿级查询的实战锤炼，但具体实施仍需结合业务场景。记住：最好的优化，是在设计阶段就避免问题。
结语 结语 结语
以上就是我们今天的内容，希望可以帮助到大家。
扫一扫
5686
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
