版权声明:本文为博主原创文章,未经博主允许不得转载。博客地址:http://www.fanlegefan.com/ https://blog.csdn.net/woloqun/article/details/82768991
公司线上presto集群在周末有大量的任务失败,查看了下机群的负载,除了coordinator,所有worker的cpu和内存基本上都耗尽了,查看日志,出现了很多worker节点被下线的情况,查看jvn进程,出现了很多次FUll GC,而且时间非常长
首先我们判断是不是网络问题,因为我们这边的数据主要是hdfs和mysql,在和网络同时沟通测试后,确定presto集群访问hdfs和mysql这两条数据链路都没有网络异常情况,并且hdfs和mysql也没有做任何配置上的修改
之后我们怀疑是否有增量的大数据查询任务(之前我们把所有的查询都存到数据库中),查询数据库,并没有增量任务,并且也没有异常查询
在确定非外界因素之后,那只有硬着头皮去调参,首先我们着手怎样减少Full GC,无奈各种调参,效果都不是很明显,再一次说明,如果你不是巨牛,jvm调参这种方案,一定要放在最后
之后我们,我们换了一种思路,减少每个实例heap内存,部署多个实例,之前每个实例heap内存都配置了55G,我们降到了40G,之前一个机器上部署了2个实例,现在变成了3个;换了部署方案后,full gc确实少一点,但是集群还是会出现崩溃的问题
想到集群负载高,我们试着着手去限制每个用户队列同时运行任务数,于是我们把之前每个用户最多运行任务数从10个降到3(这个是一步一步调下来的结果,起初尝试了8,5),果然集群基本上没有了full gc,虽然查询时间会长一点,但总算抗住了计算峰值(有钱的话就直接加机器吧)
贴个资源配置文件,大家参考下resource.json
{
"rootGroups": [
{
"name": "global",
"softMemoryLimit": "80%",
"maxRunning": 100,
"maxQueued": 1000,
"jmxExport": true,
"subGroups": [
{
"name": "adhoc_${USER}",
"softMemoryLimit": "30%",
"maxRunning": 3,
"maxQueued": 20
},
{
"name": "pipeline",
"softMemoryLimit": "20%",
"maxRunning": 3,
"maxQueued": 100,
"jmxExport": true,
"subGroups": [
{
"name": "pipeline_${USER}",
"softMemoryLimit": "10%",
"maxRunning": 3,
"maxQueued": 100
}
]
}
]
},
{
"name": "admin",
"softMemoryLimit": "100%",
"maxRunning": 100,
"maxQueued": 100,
"jmxExport": true
}
],
"selectors": [
{
"user": "presto_admin",
"group": "admin"
},
{
"source": ".*pipeline.*",
"group": "global.pipeline.pipeline_${USER}"
},
{
"group": "global.adhoc_${USER}"
}
],
"cpuQuotaPeriod": "10h"
}