在线程池中搜索特定节点,始终处于最大值

yzxexxkh  于 2021-06-14  发布在  ElasticSearch
关注(0)|答案(1)|浏览(331)

我有一个有6个节点的elasticsearch集群。堆大小被设置为50gb。(我知道建议小于32,但由于某些原因我不知道这已经被设置为50gb)。现在我看到了很多来自搜索线程池的拒绝。
这是我当前的搜索线程池:

node_name               name   active rejected  completed
1105-IDC.node          search      0 19295154 1741362188
1108-IDC.node          search      0  3362344 1660241184
1103-IDC.node          search     49 28763055 1695435484
1102-IDC.node          search      0  7715608 1734602881
1106-IDC.node          search      0 14484381 1840694326
1107-IDC.node          search     49 22470219 1641504395

我注意到两个节点总是有最大活动线程数(1103-idc.node和1107-idc.node)。即使其他节点也有拒绝,但这些节点的拒绝率最高。硬件与其他节点类似。为什么会这样?是不是因为他们有什么特别的碎片命中率更高?如果是,如何找到它们。?
另外,年轻的堆在活动线程总是最大的节点上花费了超过70毫秒(有时大约200毫秒)的时间。请在gc日志的下面几行中查找:

[2020-10-27T04:32:14.380+0000][53678][gc             ] GC(6768757) Pause Young (Allocation Failure) 27884M->26366M(51008M) 196.226ms
[2020-10-27T04:32:26.206+0000][53678][gc,start       ] GC(6768758) Pause Young (Allocation Failure)
[2020-10-27T04:32:26.313+0000][53678][gc             ] GC(6768758) Pause Young (Allocation Failure) 27897M->26444M(51008M) 107.850ms
[2020-10-27T04:32:35.466+0000][53678][gc,start       ] GC(6768759) Pause Young (Allocation Failure)
[2020-10-27T04:32:35.574+0000][53678][gc             ] GC(6768759) Pause Young (Allocation Failure) 27975M->26444M(51008M) 108.923ms
[2020-10-27T04:32:40.993+0000][53678][gc,start       ] GC(6768760) Pause Young (Allocation Failure)
[2020-10-27T04:32:41.077+0000][53678][gc             ] GC(6768760) Pause Young (Allocation Failure) 27975M->26427M(51008M) 84.411ms
[2020-10-27T04:32:45.132+0000][53678][gc,start       ] GC(6768761) Pause Young (Allocation Failure)
[2020-10-27T04:32:45.200+0000][53678][gc             ] GC(6768761) Pause Young (Allocation Failure) 27958M->26471M(51008M) 68.105ms
[2020-10-27T04:32:46.984+0000][53678][gc,start       ] GC(6768762) Pause Young (Allocation Failure)
[2020-10-27T04:32:47.046+0000][53678][gc             ] GC(6768762) Pause Young (Allocation Failure) 28001M->26497M(51008M) 62.678ms
[2020-10-27T04:32:56.641+0000][53678][gc,start       ] GC(6768763) Pause Young (Allocation Failure)
[2020-10-27T04:32:56.719+0000][53678][gc             ] GC(6768763) Pause Young (Allocation Failure) 28027M->26484M(51008M) 77.596ms
[2020-10-27T04:33:29.488+0000][53678][gc,start       ] GC(6768764) Pause Young (Allocation Failure)
[2020-10-27T04:33:29.740+0000][53678][gc             ] GC(6768764) Pause Young (Allocation Failure) 28015M->26516M(51008M) 251.447ms
lstz6jyr

lstz6jyr1#

需要注意的一点是,如果您从elasticsearch threadpool cat api获得这些统计信息,那么它只显示时间点数据,而不显示过去1小时、6小时、1天、1周的历史数据。
拒绝和完成是节点最后一次重新启动的统计数据,因此当我们试图弄清楚一些es节点是否由于错误/不平衡的碎片配置而成为热点时,这也不是很有帮助。
所以这里我们有两件非常重要的事情要弄清楚
通过按时间范围查看数据节点上的平均活动、被拒绝的请求(您只需检查高峰时间),可以确保我们知道集群中的实际热点节点,如果您有这样的工具,这将非常容易
一旦知道热点节点,查看分配给它们的分片,并将其与其他节点分片进行比较,要检查的指标很少,分片的数量,分片接收的流量更多,分片接收的查询最慢,同样的,你必须通过研究es的各种度量和api来找出其中的大部分,这些度量和api可能非常耗时,并且需要大量的es内部知识。

相关问题