ALM-50212 FE进程的老年代GC耗时累计值超过阈值 告警解释 系统每30秒周期性检查FE进程的老年代GC耗时累计值，当检查到该值超出阈值（默认值为3000ms）时产生该告警。 当系统检查到FE进程的老年代GC耗时累计值低于阈值时，告警清除。 告警属性 告警ID 告警级别 是否可自动清除

查看更多 →

置的内存不足，可能会产生更多的Java GC（垃圾收集）。当GC发生时，会发现查询性能下降。 定位思路 在Spark UI上，会发现某些executors的GC时间明显比其他executors高，或者所有的executors都表现出高GC时间。 处理步骤 登录Manager页面，选择“集群

查看更多 →

系统每30s周期性采集Presto Worker4进程的垃圾收集（GC）时间，当检测到GC时间超出阈值（连续3次检测超过5s）时产生该告警。用户可通过“运维 > 告警 > 阈值设置 > 服务 > Presto”修改阈值，当 Worker4进程GC时间小于或等于告警阈值时，告警清除。 告警属性 告警ID

查看更多 →

ALM-14014 NameNode进程垃圾回收（GC）时间超过阈值 告警解释 系统每60秒周期性检测NameNode进程的垃圾回收（GC）占用时间，当检测到NameNode进程的垃圾回收（GC）时间超出阈值（默认12秒）时，产生该告警。 垃圾回收（GC）时间小于阈值时，告警恢复。 告警属性

查看更多 →

neigh.default.gc_thresh1 net.ipv4.neigh.default.gc_thresh2 net.ipv4.neigh.default.gc_thresh3 /etc/sysctl.conf ARP表项的垃圾回收调优。 gc_thresh1：表示最小可

查看更多 →

ALM-18010 ResourceManager进程垃圾回收（GC）时间超过阈值 ALM-18011 NodeManager进程垃圾回收（GC）时间超过阈值 ALM-18012 JobHistoryServer进程垃圾回收（GC）时间超过阈值 ALM-18013 ResourceManager直接内存使用率超过阈值

查看更多 →

全量迁移失败报错，关键词“GC overhead limit exceeded” 场景描述 MongoDB->DDS实时迁移场景，全量迁移报错，日志提示信息：service DATAMOVE failed, cause by: GC overhead limit exceeded。

查看更多 →

全量同步失败报错，关键词“GC overhead limit exceeded” 场景描述 全量同步期间DRS任务报错，同步日志界面提示：service DATAMOVE failed, cause by: GC overhead limit exceeded 可能原因 业务存在大数据字段导致同步任务内存超限。

查看更多 →

图1 异常信息 根因分析 检查网络是否发生闪断，分析集群负载是否很高。 如果频繁出现Full GC, 建议排查代码，确认是否有内存泄漏。 图2 Full GC 处理步骤 如果频繁Full GC, 建议排查代码，是否有内存泄漏。 增加单TM所占的资源。 联系技术支持，修改集群心跳配置参数。

查看更多 →

errMsg String 错误描述 请求示例 { "action" : "config_gc_time", "gc_time" : 5 } 响应示例 状态码： 200 任务下发成功 { "gc_time" : 10 } 状态码： 404 错误响应 { "errCode" :

查看更多 →

errMsg String 错误描述 请求示例 { "action" : "config_gc_time", "gc_time" : 5 } 响应示例 状态码： 200 任务下发成功 { "gc_time" : 10 } 状态码： 404 错误响应 { "errCode" :

查看更多 →

> 系统”，修改参数“GC_OPTS”的值，保存配置，滚动重启Zookeeper服务，如下表所示 配置项 参考值 描述 GC_OPTS Xmx最大内存数参考值：( Master节点内存 - 16GB) * 0.65 （保守估计值） JVM用于gc的参数。仅当GC_PROFILE设置

查看更多 →

ResourceManager进程垃圾回收（GC）时间超过阈值 告警解释 系统每60秒周期性检测ResourceManager进程的垃圾回收（GC）占用时间，当检测到ResourceManager进程的垃圾回收（GC）时间超出阈值（默认12秒）时，产生该告警。 垃圾回收（GC）时间小于阈值时，告警恢复。

查看更多 →

需要查看MetaStore运行日志。 GC日志查看 HiveServer和MetaStore均有GC日志，当遇到GC问题可以查看GC日志以快速定位是否是GC导致。例如遇到HiveServer或MetaStore频繁重启就需要去看下对应的GC日志。 父主题： 使用Hive

查看更多 →

JVM or host machine (eg GC): pause of approximately 63750ms GC pool 'ParNew' had collection(s): count=1 time=0ms GC pool 'ConcurrentMarkSweep'

查看更多 →

> 系统”，修改参数“GC_OPTS”的值，保存配置，滚动重启Zookeeper服务，如下表所示 配置项 参考值 描述 GC_OPTS Xmx最大内存数参考值：( Master节点内存 - 16GB) * 0.65 （保守估计值） JVM用于gc的参数。仅当GC_PROFILE设置

查看更多 →

/proc/sys/net/ipv4/neigh/default/gc_thresh* 128 512 1024 [root@xxxxx ~]# echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 [root@xxxxx ~]# echo

查看更多 →

）。 注意堆内存设置时，可以设置“-Xms” “-Xmx”近似相等，从而避免每次GC后调整堆的大小，从而引起性能下降。 同时，并且“-Xmx”与“XX:MaxPermSize”之和不得大于该节点 服务器 的实际物理内存值。 重启受影响的服务或实例，观察界面告警是否清除。 是，处理完毕。

查看更多 →

可能原因 HiveServer或者MetaStore实例在启动的时候发生异常，无法正常启动。如，当修改MetaStore/HiveServer GC参数时，可通过查看对应进程的启动日志，如hiveserver.out(hadoop-omm-jar-192-168-1-18.out)文件排查。

查看更多 →

在界面左侧树单击环境，单击“基础监控”，切换至基础监控页签。 图1 基础监控 在基础监控页签选择您想要查看的“实例名称”，可以查看该实例的应用监控数据。 gc 对gc进行监控，展示gc时间以及gc次数指标的趋势图。 cpu 对cpu进行监控，展示cpu使用率的趋势图。 线程 对线程进行监控，展示BLOCKED状态线

查看更多 →

access_log.<DATE>.log Tomcat访问日志。 catalina.out Tomcat服务运行日志。 gc-worker.log RangerAdmin的GC日志。 postinstallDetail.log 实例安装前启动后工作日志。 prestartDetail.log

查看更多 →