问题分析报告--读取ORC文件报seek错误

问题分析报告--读取ORC文件报seek错误

1、问题描述

1.1 基本信息[Basic Information]

• 集群规模：37+3台物理机，每台128G内存；CPU：2*16C；SATA磁盘，2T*12
• hadoop社区版本：**
• 商业版本：FusionInsight_HD_V100R002C60U10
• MetaStore：高斯数据库（Postgresql）

1.2 问题描述[Problem Description]

• C60U10版本YARN集群在高并发任务状态下运行2天左右可能导致NM资源本地化性能下降，进而导致任务整体执行效率下降。

2、问题分析[Problem Analysis]

1. 分析job性能变慢，主要体现为Container localized执行变慢

Task Slow logs:

 

Task Quick logs:

通过分析日志发现, container 执行变慢主要卡在ResourceLocalizationService锁的竞争上：

 

下图为随机挑选出来的一个container运行慢的时候的jstack打印信息，发现这个container等待这个锁等待了22s之久：

 

2. 分析锁内代码执行慢的原因：

通过获取操作系统的统计数据osinfo，发现在container localized过程中会调用ls命令获取本地目录的文件基本信息出现了X状态（Linux process state: X (TASK_DEAD - EXIT_DEAD), the exit status, the process is about to be destroyed.），该状态被捕捉多次，说明这个命令执行在os层占用时间较长。

 

 

3. 排查ls变慢的原因，发现NM的堆外内存持续增长

1） NM的内存使用持续增长：

 

2）通过打印NM的堆外内存使用，发现大部分堆外内存使用均来自leveldb，内存分析截图如下：

利用pmap命令将NM使用的内存信息dump下来，然后用gdb将指定寻址空间的堆外内存dump到本地：

 

通过将二进制内存文件转化为可见字符，可知，当前的堆外内存主要来自leveldB。

4. NM堆外内存的持续上涨到一定程度后，会导致NM内部调用os的命令执行变慢，从而导致YARN的NM的container本地化锁竞争加剧，最终导致业务性能下降。最后，通过在生产环境上将NM的recovery特性关闭，消除了levelDB导致堆外内存持续上涨的问题，从而解决了业务执行48小时后会出现性能下降的问题。

3、根本原因[Root Cause]

分析为YARN的recovery特性会依赖leveldb，而leveldb的数据存储会占用堆外内存，从而导致堆外内存上涨，当堆外内存的堆积会导致os占用内存无法及时的释放，而在大量任务并发时，业务也需要占用大量内存，内存的紧张会导致任务在资源本地化的过程中执行os的“ls  -ld” 命令变慢；同时每个contaienr的localized地方存在锁的竞争，命令执行变慢，会使该锁的竞争恶化，从而表现在业务运行一段时间后，性能逐渐变慢。

4、解决措施[Corrective Action]

4.1 最终解决措施[Solution]

1. 通过关闭YARN的NodeManager的recovery特性，即配置yarn.nodemanager.recovery.enabled参数为：false

 4.2 最终解决措施[Solution]

1. 解决leveldb堆外内存上涨（C60U10SPC003补丁）
2. 优化container 本地化锁（C60U10SPC003补丁）
3. 将leveldb的数据目录规划到数据盘，不挂载到系统盘上（磁盘规划）

5、解决措施[Corrective Action]

4.1 最终解决措施[Solution]

1. 观察系统内存占用情况，检查是否存在内存使用异常

2. 通过如下手段排查，确定是否是同一问题：

1） 确认是否开启NM的recovery特性（yarn.nodemanager.recovery.enabled：true）；

2） 通过top -p PID查看NM进程的内存RES使用是否超过JVM堆内存的2倍以上；

3） 查看{yarn.nodemanager.recovery.dir}/yarn-nm-state目录下的xx.sst文件数目是否超过2000+；

注：{yarn.nodemanager.recovery.dir}在NM的后台配置文件中查看：

/opt/huawei/Bigdata/FusionInsight/etc/x_x_NodeManager/yarn-site.xml（其中x表示某一数字）

yarn.nodemanager.recovery.dir

/srv/BigData/tmp/yarn-nm-recovery

4） NM日志中排查是否有大量的“Localizer failed”、“InterruptedException”；

3. 如确认是同一问题，请参照5.1临时规避。