我们在压力测试中，通过压力测试，发现translog文件过多，导致OS句柄消耗完毕。搜了社区问题，和这个很类似：https://elasticsearch.cn/question/1343。
但我们当前版本已经是6.1.3了，难道在这个版本还存在类似问题？或者是某个地方没配置好？
在指定index的某个shard下，translog文件个数超过13万。
此index的setting信息如下：
curl -XGET -k -u : "http://127.0.0.1:9200/myindex- ... ot%3B
{
"myindex-002" : {
"settings" : {
"index" : {
"refresh_interval" : "30s",
"number_of_shards" : "60",
"provided_name" : "myindex-002",
"creation_date" : "1526301558029",
"number_of_replicas" : "0",
"uuid" : "iM0QsRb3SXuDpz6ZbBi-wg",
"version" : {
"created" : "6010399"
}
}
}
}
}
但我们当前版本已经是6.1.3了，难道在这个版本还存在类似问题？或者是某个地方没配置好？
在指定index的某个shard下，translog文件个数超过13万。
此index的setting信息如下：
curl -XGET -k -u : "http://127.0.0.1:9200/myindex- ... ot%3B
{
"myindex-002" : {
"settings" : {
"index" : {
"refresh_interval" : "30s",
"number_of_shards" : "60",
"provided_name" : "myindex-002",
"creation_date" : "1526301558029",
"number_of_replicas" : "0",
"uuid" : "iM0QsRb3SXuDpz6ZbBi-wg",
"version" : {
"created" : "6010399"
}
}
}
}
}
4 个回复
kennywu76 - Wood
赞同来自: famoss 、rochy 、laoyang360
为了加速热索引的recovery， 6.x开始对于translog不再是flush以后立即清除，而是保留一定的大小，由以下两个参数控制：
保留一定量的translog的目的，是为了出现热索引recovery情况的时候，借助保留的translog和seqno (也是6.x引入的，记录已经提交到lucene的文档序列号)， 可以免去跨结点的shard文件拷贝消耗，直接从translog快速恢复数据。
由于保留了一定时间的translog不清除，那么判断是否需要flush，以及flush的时候清除哪些文件的的条件就复杂了一些。需要比较哪些translog里的doc已经全部提交，哪些还未提交或者部分提交。 这些判断是通过比较translog里保留的seqno和local checkpoint记录的seqno来做出的。
但是这个特性实现上看起来有些bug，在一些极端场景造成了flush死循环。 官方尝试在6.1.3/6.2.0修复这个问题( pull/28350 )， 但问题并未真正解决。
在用户报告问题以后，官方又发布了6.2.4 (pull/29125)， 经过我们生产集群的验证，升级到6.2.4以后再未遇到类似的问题。
kennywu76 - Wood
赞同来自: zhuo
rockybean - Elastic Certified Engineer, ElasticStack Fans，公众号：ElasticTalk
赞同来自:
https://github.com/elastic/ela ... 29097
建议用 6.2.4 再测试一下
kennywu76 - Wood
赞同来自: