code4j

code4j

coder

威望 : 6 积分 : 1125 赞同 : 9 感谢 : 0

擅长话题

更多 »回复

0

看了下日志内容,你的内存分配还是蛮大的,内存越大,一次gc耗时也会越多,old回收的时候 duration 1.9m意思是一分钟吧,应用等几秒都受不了的。年轻带回收很快,日志显示几秒钟也不科学,我觉得你应该适当给幸存区分配些空间。而且我看了你的线程数配了至少3...

1

写后立马读的需求场景看能不能避免下,还有, query是走倒排索引查询的所以会出现refresh未执行搜索不到的情况,但是如果你用get,也就是通过id查询的话,他会先从translog拿一下,写translog是写操作的第一步,就不受refresh影响了。2...

0

我们是服务层记录查询语句。说白了就是肯定你有个服务或者 应用去调用查询语句,在那个服务或者应用中把query dsl 通过日志打下来就行了

0

有JVM崩溃日志,之前我们处理过一起,日志集群,有六十多个日志索引,然后有人使用通配符查询这六十多个索引的内容,结果每天都有节点丢失。。  主要就是内存不够,而且使用不当

0

楼上推荐修改线程模型的方案,其实我认为只能短时间缓解但是不能根治,调整不当容易导致速度更慢  你要解决的问题是如何让请求处理变得更快,队列本身就是解决上游请求高峰的一个方案,所以如果队列都承载不了,考虑提升处理速度,或者扩容。 如果写入慢,提升索引写入速度,针...

更多 »发问

2

171 次浏览  • 4 个关注   • 2018-05-16

1

92 次浏览  • 2 个关注   • 2018-05-15

3

167 次浏览  • 5 个关注   • 2018-05-11

1

163 次浏览  • 3 个关注   • 2018-04-10

2

243 次浏览  • 2 个关注   • 2018-04-08

发问

回复

文章

最新动态

详细资料

个人成就:

威望: 6 积分: 1125 赞同: 9 感谢: 0

最后活跃:
45 秒前
擅长话题:
es 2   0
gc频繁 1   0
集群重启 1   0
elasicsearch 6   0