使用 dmesg 来查看一些硬件或驱动程序的信息或问题。

es yong gc将近1s,该如果平滑调优

Elasticsearch | 作者 冯坤 | 发布于2017年08月28日 | 阅读数:1679

es主要用于产品业务搜索上
分配给jvm 32g, 数据量在1亿左右。偶尔会出现young gc 1s情况,
这对于线上业务是不能忍受的。
```
[node-3] [gc][young][2822976][23514] duration [874ms], collections [1]/[1.2s], total [874ms]/[15.6m], memory [18.7gb]->[17.9gb]/[31.8gb]
````
我想知道如何保证线上正常运行的情况下进行调优?
目前想到的是提高yong gc的频率,如果平滑调参?
谢谢
已邀请:

kennywu76 - Wood^Trip.com

赞同来自: 冯坤 novia kepmoving keehang guoliang_1992 DimonHo code4j更多 »

首先分配给ES JVM的内存应该略小于32GB,比较保险的设置是30GB。 

其次,ES一端出现1s左右的Young GC时,通常需要调优的是索引的mapping,数据写入的方式,以及查询和聚合语句本身。 高并发下,如果查询本身写得不够好,执行比较慢,或者需要读取大量的数据,产生垃圾的速度快,数据对象被持有的时间长,GC压力加大,时间变长是不可避免的。 你无法通过调优JVM参数去满足各式各样的查询、各式各样的业务访问模式对响应时间的要求。

我见过几个查询写的有问题,造成CPU很高,GC耗时增加的场景。 研发人员在不理解ES的情况下,通常怀疑ES的JVM需要调优,而后证实是查询的高消耗带来的长时间GC。 这时候长时间GC是果,不是因。 

另外“偶尔”要看是多频繁,并且是相对并发量和业务搜索的吞吐量来看。 采集业务搜索的响应时间进行分析比较靠谱,比如响应时间的99%线是多少? 要求100%响应时间小于多少不太现实,特别是高并发场景下的数据型应用,在自己力所能及的基础上,还是需要适当和业务研发做一些battle

cyberdak - 58.com - 长期内推58

赞同来自: Loading Zhang

JVM配置还配置了哪些?
 
如果是cms gc的可以切换到G1上,然后让G1更新 allocate ratio 来觉得new gen要多大,我现在非常讨厌CMS GC这种参数一大堆的gc。可以输出loggc日志,然后使用gc工具看一下gc的情况。gc的相关配置文件在es的配置文件已经默认有了,去开启就行了。一份有用的gc日志设置可以参考:http://t.cn/RNPeRaF  .gc日志分析工具 http://gceasy.io.
 
另外这种提问可以把 env 更详细得写出来,否则群众看到还是一脸懵逼,因为现有的信息不够判断情况。某些github项目的issue格式就比较好,上来就要求填写多少env相关的数据。

冯坤

赞同来自:

谢谢您的及时回复, 为我指明了查问题的方向~   受教~

冯坤

赞同来自:

谢谢回答, jvm用的都是默认配置

要回复问题请先登录注册