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的频率，如果平滑调参？
谢谢
分配给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的频率，如果平滑调参？
谢谢
4 个回复
kennywu76 - Wood
赞同来自: 冯坤 、novia 、kepmoving 、keehang 、guoliang_1992 、DimonHo 、code4j更多 »
其次，ES一端出现1s左右的Young GC时，通常需要调优的是索引的mapping，数据写入的方式，以及查询和聚合语句本身。 高并发下，如果查询本身写得不够好，执行比较慢，或者需要读取大量的数据，产生垃圾的速度快，数据对象被持有的时间长，GC压力加大，时间变长是不可避免的。 你无法通过调优JVM参数去满足各式各样的查询、各式各样的业务访问模式对响应时间的要求。
我见过几个查询写的有问题，造成CPU很高，GC耗时增加的场景。 研发人员在不理解ES的情况下，通常怀疑ES的JVM需要调优，而后证实是查询的高消耗带来的长时间GC。 这时候长时间GC是果，不是因。
另外“偶尔”要看是多频繁，并且是相对并发量和业务搜索的吞吐量来看。 采集业务搜索的响应时间进行分析比较靠谱，比如响应时间的99%线是多少？ 要求100%响应时间小于多少不太现实，特别是高并发场景下的数据型应用，在自己力所能及的基础上，还是需要适当和业务研发做一些battle
cyberdak
赞同来自: Loading Zhang
如果是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相关的数据。
冯坤
赞同来自:
冯坤
赞同来自: