作为一个ES小白,没有实战经验,对数据量与ES的集群规划没有啥概念,希望有实战过的兄弟不吝赐教。
我们现在线上ES的情况为:
数据量1TB左右,文档数20亿左右,线上3个ES节点(阿里云的8核32G配SSD云盘),划分了4个索引,每个索引10个主分片(副本数1,每个分片差不多10几G),采用父子文档结构。另外集群上还有一些文档数较小的索引(百万级左右)。目前那4个大索引每天请求数也就几十次吧(写比较频繁,50~500/s),小索引的查询频次在10~40次/s
遇到的问题:
现在大索引的查询请求都很慢(用户反映经常刷不出来,每次一查,load average就涨到10以上,集群跑一段时间后内存就会涨上去,老年代GC回收变得频繁),而且会影响到小索引的查询请求。
疑问:
(1)是不是该加节点了(3个会不会太少),3个节点纵向升级两回了,运维出于成本考虑,都不太愿意给加机器。本人也没有实战经验,这样的数据规模大概ES集群的硬件配置应该是怎样的?
(2)截止目前,最近线上集群已经崩掉两回了,每次都是主节点先挂掉。是否有必要将主节点与数据节点独立划分出来(之前是混在一起的)
(3)目前业务上还没有到做数据冷热分离的地步。对于现有的数据量,我的索引及分片划分方式是不是不合理?应该如何更好地划分。
我们现在线上ES的情况为:
数据量1TB左右,文档数20亿左右,线上3个ES节点(阿里云的8核32G配SSD云盘),划分了4个索引,每个索引10个主分片(副本数1,每个分片差不多10几G),采用父子文档结构。另外集群上还有一些文档数较小的索引(百万级左右)。目前那4个大索引每天请求数也就几十次吧(写比较频繁,50~500/s),小索引的查询频次在10~40次/s
遇到的问题:
现在大索引的查询请求都很慢(用户反映经常刷不出来,每次一查,load average就涨到10以上,集群跑一段时间后内存就会涨上去,老年代GC回收变得频繁),而且会影响到小索引的查询请求。
疑问:
(1)是不是该加节点了(3个会不会太少),3个节点纵向升级两回了,运维出于成本考虑,都不太愿意给加机器。本人也没有实战经验,这样的数据规模大概ES集群的硬件配置应该是怎样的?
(2)截止目前,最近线上集群已经崩掉两回了,每次都是主节点先挂掉。是否有必要将主节点与数据节点独立划分出来(之前是混在一起的)
(3)目前业务上还没有到做数据冷热分离的地步。对于现有的数据量,我的索引及分片划分方式是不是不合理?应该如何更好地划分。
4 个回复
kennywu76 - Wood
赞同来自: laoyang360 、strglee 、zyb1994111
从你贴的监控图标看,10:00 - 14:00那段时间, old gc非常频繁,但是GC过后,heap占用率并没有下降,并且一直呈缓慢上升趋势,说明有不能被回收的对象一直在增加。 直到接近16:00的时候,监控曲线断开(应该是有结点内存OOM了导致监控数据缺失)。 如果这个是你所说的每次都是“主结点”挂掉的情况,我凭经验推断,比较大的可能性是集群有大量的状态更新任务在堆积,耗尽了主结点的内存。 你可以用 /_cat/pending_tasks 确认一下。
如果是我推测的这种情况,那么看下这些是什么任务,找出产生这些任务的根源,对症下药。
kennywu76 - Wood
赞同来自: the_best
这块的内存消耗可以用下面的方法查看:
parent-child适用的场景是少数parent对很多child, 如果你的数据特性是很多的parent,然后每个parent的child不是很多,那么查询的开销会非常高。
相关资料参考:
另外status字段应该设置为keyword, 原因参考:https://www.ksh17j.com/article/446 。 不过相对来说,主要的问题还是上面说的parent-child连接。
the_best
赞同来自:
{
"from": 0,
"size": 50,
"query": {
"bool": {
"must": [
{
"bool": {
"must": [
{
"bool": {
"must": [
{
"query_string": {
"query": "5",
"fields": [
"status^1.0"
],
"use_dis_max": true,
"tie_breaker": 0.0,
"default_operator": "or",
"auto_generate_phrase_queries": false,
"max_determinized_states": 10000,
"enable_position_increments": true,
"fuzziness": "AUTO",
"fuzzy_prefix_length": 0,
"fuzzy_max_expansions": 50,
"phrase_slop": 0,
"escape": false,
"split_on_whitespace": true,
"boost": 1.0
}
},
{
"has_child": {
"query": {
"bool": {
"must": [
{
"query_string": {
"query": "152836522601000003",
"fields": [
"signer_user_id^1.0"
],
"use_dis_max": true,
"tie_breaker": 0.0,
"default_operator": "or",
"auto_generate_phrase_queries": false,
"max_determinized_states": 10000,
"enable_position_increments": true,
"fuzziness": "AUTO",
"fuzzy_prefix_length": 0,
"fuzzy_max_expansions": 50,
"phrase_slop": 0,
"escape": false,
"split_on_whitespace": true,
"boost": 1.0
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1.0
}
},
"type": "contract_signer",
"score_mode": "none",
"min_children": 0,
"max_children": 2147483647,
"ignore_unmapped": false,
"boost": 1.0
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1.0
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1.0
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1.0
}
},
"sort": [
{
"utime": {
"order": "desc"
}
}
],
"highlight": {
}
}
profile API的耗时分析如下:
感觉分片耗时都消耗在build_scorer阶段或next_doc阶段。
yang009ww
赞同来自: