问题分析报告--读取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之久:
分析锁内代码执行慢的原因:
通过获取操作系统的统计数据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。
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]
- 通过关闭YARN的NodeManager的recovery特性,即配置yarn.nodemanager.recovery.enabled参数为:false
4.2 最终解决措施[Solution]
- 解决leveldb堆外内存上涨(C60U10SPC003补丁)
- 优化container 本地化锁(C60U10SPC003补丁)
- 将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临时规避。