绊脚石乃是进身之阶。

合并查询多个索引时速度很慢,希望各位提供一下优化思路

Elasticsearch | 作者 Yanchao Ma | 发布于2019年10月17日 | 阅读数:2943

1、背景说明:
六台服务器:内存-32G,CPU-8,硬盘200G
六节点(elasticsearch版本-5.6.3):角色配置-node.master: true node.data: true,内存16G (机器剩余内存也部署了一些其它程序)
集群整体情况:106-indices 563-shards 317,749,447-docs 834.63GB
另外2中检索的索引都有相同的设置:
{
"index": {
"routing": {
"allocation": {
"total_shards_per_node": "1"
}
},
"refresh_interval": "5s",
"number_of_shards": "3",
"translog": {
"flush_threshold_size": "1.6gb"
},
"provided_name": "facebook_info_small",
"merge": {
"scheduler": {
"max_thread_count": "1"
}
},
"creation_date": "1564459882716",
"number_of_replicas": "0",
"uuid": "s66dKJX_RBuT2xs89kGQnQ",
"version": {
"created": "5060399"
}
}
}

2、遇到的问题:
执行以下合并查询多个索引(每个索引3个分片)时有时会很慢6~7s左右。最慢:"took":6213;最快:"took":128。这种情况有什么比较好的优化方法嘛?为什么查询耗时会有这么大的差距?
curl -XPOST http://192.168.167.28:9600/facebook_info_small,mblog_info_small,video_info_small,blog_small,forum_threads_small,news_small,newspaper_small,think_tank_small,youtube_info_small,wechat_info_small,appdata_small,instagram_thread_small,twitter_info_small/monitor_small/_search -d '{"size":1,"query":{"bool":{"filter":{"bool":{"must":[{"range":{"pubtime":{"gte":"2019-10-14 00:00:00","lte":"2019-10-17 11:47:10"}}}]}}}},"_source":["gid"],"from":0,"sort":[{"pubtime":"DESC"}]}'


我初步的判断可能时操作系统缓存不够用,某些分片查询较慢,导致拖慢整体速度,如果是这样就完全是服务器配置性能问题了,有没有好的优化思路呢?(另外这些索引的数据会用delete_by_query接口删除只保留三天的,每天凌晨会执行一次forcemeger操作)
已邀请:

printf_uck - 1024

赞同来自: Yanchao Ma

这个格式让人看着很难受,建议换下排版,另外要说清楚 ES版本,mapping等信息

laoyang360 - 《一本书讲透Elasticsearch》作者,Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自: Yanchao Ma

机器剩余内存也部署了一些其它程序)?这点很重要。

1,核实下慢日志
2,dsl 加上profile:true分析下
3,推荐阅读:https://mp.weixin.qq.com/s/Fw4RW9H_qLIP4MeqOZ_FMw

要回复问题请先登录注册