问题分析报告--读取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:

 

OC AES 中文长度问题 oc ask问题_Problem

Task Quick logs:


OC AES 中文长度问题 oc ask问题_执行效率_02

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


OC AES 中文长度问题 oc ask问题_Problem_03

 

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

 

OC AES 中文长度问题 oc ask问题_执行效率_04

分析锁内代码执行慢的原因:

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


OC AES 中文长度问题 oc ask问题_Problem_05


 

OC AES 中文长度问题 oc ask问题_执行效率_06

 

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

1) NM的内存使用持续增长:


OC AES 中文长度问题 oc ask问题_Problem_07



 

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

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

 

OC AES 中文长度问题 oc ask问题_问题分析_08

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


OC AES 中文长度问题 oc ask问题_问题分析_09



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]


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


通过如下手段排查,确定是否是同一问题:


确认是否开启NM的recovery特性(yarn.nodemanager.recovery.enabled:true);


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


查看{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表示某一数字) 
  
   
<property>
   
<name>yarn.nodemanager.recovery.dir</name>
   
<value>/srv/BigData/tmp/yarn-nm-recovery</value>
   
</property>


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


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