【详述】写入过程发现thrift-server-pool飙升达到最高，然后 fe 频繁OOM出现，写入过程有flink和insert overwrite select * from hive表，大可能是后者引起OOM, starrocks JVM XMX设置32Goom ,设置64G依然OOM, 经过自己分析大可能是内存泄露
【背景】尝试了3.1.11,3.2.6,3.2.7的版本，依然有这样的问题
【业务影响】
【是否存算分离】否
【StarRocks版本】3.1.11,3.2.6,3.2.7
【集群规模】3fe+80be
【机器信息】40C192G 12*1T SSD
【联系方式】论坛
【附件】
- fe.log/beINFO/相应截图
- 慢查询：
- Profile信息，获取Profile，通过Profile分析查询瓶颈
- 并行度：1
- pipeline是否开启：是
- be节点cpu和内存使用率截图
heapdump过大超过32G,采用ParseHeapDump.sh heapdump.hprof org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top_components的结果
java_pid40682_Leak_Suspects.zip (224.5 KB) [java_pid40682_System_Overview.zip|attachment]java_pid40682_Top_Components.zip (330.5 KB) (upload://qsHhjLEDOZ9V0doupMKPP4o9aiF.zip) (135.7 KB)
相关工具 mat分析截图：
跟进这个大的对像，发现每个thrift-server-pool都有一份一模一样的olaptable数据应该要复用
对像大致内容：
{
“comment”: “”,
“indexIdToMeta”: {
“12219”: {
“schemaHash”: 1730590400,
“storageType”: “COLUMN”,
“keysType”: “DUP_KEYS”,
“schemaId”: 12219,
“indexId”: 12219,
“isColocateMVIndex”: false,
“shortKeyColumnCount”: 3,
“dbId”: 0,
“schemaVersion”: 0,
“schema”: [
{
“comment”: “”,
“isAutoIncrement”: false,
“stats”: {
“maxSize”: -1,
“numDistinctValues”: -1,
“avgSerializedSize”: -1.0,
“numNulls”: -1
“lastFailedVersion”: -1,
“lastSuccessVersion”: 2,
“backendId”: 10011,
“rowCount”: 211135,
“state”: “DECOMMISSION”,
“version”: 2,
“dataSize”: 20133914,
“id”: 2721133,
“minReadableVersion”: 0
},
{
“lastFailedVersion”: -1,
“lastSuccessVersion”: 2,
“backendId”: 10332,
“rowCount”: 211135,
“state”: “NORMAL”,
“version”: 2,
“dataSize”: 20136612,
“id”: 2730970,
“minReadableVersion”: 1
}
],
“clazz”: “LocalTablet”,
“signature”: -1,
“id”: 2721130,
“checkedVersion”: 2
},
以上这样的数据，有几十万份，严重消耗内存