【大内存服务GC实践】- “ParNew+CMS”实践案例 (一)- NameNode YGC诊断优化

这是"大内存服务GC实践"的第三篇文章,前面两篇文章分别系统地介绍了"ParNew+CMS"组合垃圾回收器的原理以及FullGC的一些排查思路。分别见
  1. 【大内存服务GC实践】- 一文看懂”ParNew+CMS”垃圾回收器
  2. 【大内存服务GC实践】- “ParNew+CMS”实践案例 : HiveMetastore FullGC诊断优化
本篇文章重点结合生产线上NameNode RPC毛刺这个现象,分析两起严重的YGC问题。NameNode是HDFS服务最核心的组件,大数据任务读写文件都需要请求NameNode,该服务一旦出现RPC处理毛刺,就可能会引起上层大数据平台离线、实时任务的延迟甚至异常。公司内部NameNode采用"ParNew+CMS"组合垃圾回收器。

案例一 NameNode升级之后RPC大毛刺问题探究

问题背景

随着HDFS集群规模的增大,NameNode性能压力越来越大,因此我们结合社区新版本的优化进行了内部分支的优化并发布上线。上线之后观察了一周,发现上线后RPC排队毛刺明显变大变多。如下图所示

问题分析

为什么RPC排队毛刺会出现?

按照经验来看,NameNod...

继续阅读

【大内存服务GC实践】- “ParNew+CMS”实践案例 : HiveMetastore FullGC诊断优化

Metastore服务是Hive的核心组成部分,是整个hadoop大数据体系的元数据基石,所有数据表相关schema信息、partition信息、元数据统计信息等都存储在Metastore所依赖的MySQL中,通过Metastore服务执行各种元数据操作。Metastore服务一旦长时间异常,所有依赖服务(诸如HiveServer、Spark、Impala等)就都会出现功能或服务异常。
Metastore是一个相对成熟的服务,通常情况下不会发生特殊的异常。但和所有的数据库系统一样,一旦上层业务使用姿势不对的话,是可能导致发生一些莫名其妙的系统异常。这篇文章重点介绍两起因为上层业务使用用法不恰当导致Metastore服务频繁FGC,底层MySQL负载飙升问题。

线上案例一

之前有段时间,Hive运维反馈三天两头Metastore服务会发生FGC,发生FGC之后只能通过重启来解决,好在重启对业务的影...

继续阅读