yarn oom问题一例-低调大师

yarn oom问题一例

2017-11-20 578

线上部分job运行失败，报OOM的错误:

因为是maptask报错，怀疑是map数量过少，导致oom，因此调整参数，增加map数量，但是问题依然存在。看来和map的数量没有关系。

通过jobid查找jobhistory中对应的日志信息，定位到出错的task id和对应的host.通过日志查看出问题的containerid.

由于container是由RM进行分配的，查看RM的日志，可以看到container的分配情况：

比如下面的例子：

 
         2014-05-06 16:00:00,632 INFO org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FSSchedulerNode: Assigned container container_1399267192386_43455_01_000037 of capacity <memory:1536, vCores:1> on host xxxx:44614, 
         which 
         currently has 4 containers, <memory:6144, vCores:4> used and <memory:79872, vCores:42> available

可以看到container的id,host和内存大小，cpu 大小。

进一步查看NM的相关container日志：

 
         2014-05-05 10:14:47,001 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.ContainerManagerImpl: Start request 
         for 
         container_1399203487215_21532_01_000035 by user hdfs 
        
         2014-05-05 10:14:47,001 INFO org.apache.hadoop.yarn.server.nodemanager.NMAuditLogger: USER=hdfs IP=10.201.203.111       OPERATION=Start Container Request       TARGET=ContainerManageImpl      RESULT=SUCCESS  APPID=application_1399203487215_21532   CONTAINERID=container_1399203487215_21532_01_000035
        
         2014-05-05 10:14:47,001 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.application.Application: Adding container_1399203487215_21532_01_000035 to application application_1399203487215_21532
        
         2014-05-05 10:14:47,055 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.container.Container: Container container_1399203487215_21532_01_000035 transitioned from NEW to LOCALIZING
        
         2014-05-05 10:14:47,058 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Created localizer 
         for 
         container_1399203487215_21532_01_000035 
        
         2014-05-05 10:14:47,060 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Writing credentials to the nmPrivate 
         file 
         /home/vipshop/hard_disk/10/yarn/local/nmPrivate/container_1399203487215_21532_01_000035
         .tokens. Credentials list: 
        
         2014-05-05 10:14:47,412 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.container.Container: Container container_1399203487215_21532_01_000035 transitioned from LOCALIZING to LOCALIZED
        
         2014-05-05 10:14:47,454 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.container.Container: Container container_1399203487215_21532_01_000035 transitioned from LOCALIZED to RUNNING
        
         2014-05-05 10:14:47,493 INFO org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor: launchContainer: [
         bash
         , 
         /home/vipshop/hard_disk/6/yarn/local/usercache/hdfs/appcache/application_1399203487215_21532/container_1399203487215_21532_01_000035/default_container_executor
         .sh] 
        
         2014-05-05 10:14:48,827 INFO org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor: Copying from 
         /home/vipshop/hard_disk/10/yarn/local/nmPrivate/container_1399203487215_21532_01_000035
         .tokens to 
         /home/vipshop/hard_disk/11/yarn/local/usercache/hdfs/appcache/application_1399203487215_21532/container_1399203487215_21532_01_000035
         .tokens 
        
         2014-05-05 10:14:49,169 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Starting resource-monitoring 
         for 
         container_1399203487215_21532_01_000035 
        
         2014-05-05 10:14:49,305 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Memory usage of ProcessTree 21209 
         for 
         container-
         id 
         container_1399203487215_21532_01_000035: 66.7 MB of 1.5 GB physical memory used; 2.1 GB of 3.1 GB virtual memory used 
        
         2014-05-05 10:14:53,063 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Memory usage of ProcessTree 21209 
         for 
         container-
         id 
         container_1399203487215_21532_01_000035: 984.1 MB of 1.5 GB physical memory used; 2.1 GB of 3.1 GB virtual memory used 
        
         2014-05-05 10:14:56,379 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Memory usage of ProcessTree 21209 
         for 
         container-
         id 
         container_1399203487215_21532_01_000035: 984.5 MB of 1.5 GB physical memory used; 2.1 GB of 3.1 GB virtual memory used 
        
         .......
        
         2014-05-05 10:19:26,823 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Memory usage of ProcessTree 21209 
         for 
         container-
         id 
         container_1399203487215_21532_01_000035: 1.1 GB of 1.5 GB physical memory used; 2.1 GB of 3.1 GB virtual memory used 
        
         2014-05-05 10:19:27,459 INFO org.apache.hadoop.yarn.server.nodemanager.NMAuditLogger: USER=hdfs IP=10.201.203.111       OPERATION=Stop Container Request        TARGET=ContainerManageImpl      RESULT=SUCCESS  APPID=application_1399203487215_21532   CONTAINERID=container_1399203487215_21532_01_000035
        
         2014-05-05 10:19:27,459 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.container.Container: Container container_1399203487215_21532_01_000035 transitioned from RUNNING to KILLING
        
         2014-05-05 10:19:27,459 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch: Cleaning up container container_1399203487215_21532_01_000035
        
         2014-05-05 10:19:27,800 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.container.Container: Container container_1399203487215_21532_01_000035 transitioned from KILLING to CONTAINER_CLEANEDUP_AFTER_KILL

可以看到，虽然container分配的内存为1.5，但是在使用到1.1G（1.1 GB of 1.5 GB physical memory used）时task被kill掉了。。还有400多M的剩余，看来不是task的整个内存大小分配的太小导致，比较像perm的问题（默认为64m）

更新mapred的设置如下：

 
         <
         property
         > 
        
         <
         name
         >mapreduce.map.java.opts</
         name
         > 
        
         <
         value
         >-Xmx1280m -Xms1280m -Xmn256m -XX:SurvivorRatio=6 -XX:MaxPermSize=128m</
         value
         > 
        
         </
         property
         > 
        
         <
         property
         > 
        
         <
         name
         >mapreduce.reduce.java.opts</
         name
         > 
        
         <
         value
         >-Xmx1280m -Xms1280m -Xmn256m -XX:SurvivorRatio=6 -XX:MaxPermSize=128m</
         value
         > 
        
         </
         property
         > 
        
         <
         property
         > 
        
         <
         name
         >mapred.child.java.opts</
         name
         > 
        
         <
         value
         >-Xmx1280m -Xms1280m -Xmn256m -XX:SurvivorRatio=6 -XX:MaxPermSize=128m</
         value
         > 
        
         <
         final
         >true</
         final
         > 
        
         </
         property
         >

重新运行job，成功。

其实对应java的oom问题来说，最好的方法是打印gc的信息和dump内存的堆栈，然后使用MAT一类的工具来进行分析。

本文转自菜菜光 51CTO博客，原文链接：http://blog.51cto.com/caiguangguang/1407424，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/434569

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

zabbix 自定义LLD

线上部分实时job是用storm开发的，为了监控数据的延迟，在storm处理日志的时候会把日志的时间插入到redis中，然后通过zabbix做延迟的监控。由于经常有新的job上线，手动配置监控项就变得比较麻烦，为了解放生产力，还是需要搞成自动化。之前添加网卡和分区监控的时候用了LLD的功能，并用了其内置的宏变量，新版本的zabbix是支持custom LLD的，实现步骤如下： 1.在模板中设置一个discovery rule ( UserParameter Key)，调用脚本，返回zabbix规定的json数据（返回自定义的宏变量），并正确设置的discovery（比如filter等）这里通过官方文档并结合线上的agent日志，可以看到zabbix规定的数据格式 1 2 3 4 5 6 7 8 9 10 11 12 143085:20141127:000548.967Requested[vfs.fs.discovery] 143085:20141127:000548.967Sendingback[{ "data" :[ { "{#FSNAME}" : "\/" , "{#F...

2017-11-21

720

hive集成kerberos问题1

在hdfs+mapred+impala+kerberos运行正常后，开始测试hive+kerberos。hive0.11之后开始支持kerberos的验证，hive主要有两种访问方式，一种方法是shell运行，即直接运行hive命令，另一种方法时启动hiveserver，然后通过jdbc或odbc进行验证，其中第二种方法可以通过hive0.11的beeline进行测试。在使用hive shell运行时，主要遇到下面几个问题： 1.权限验证问题。在hive操作hdfs数据的时候，权限是分为两层的，一个是hive层面的权限控制，主要是控制表的权限，一个是hdfs文件的权限控制，控制用户的读写操作。表的相关权限主要是写在hive的元数据库中，主要是TBL_PRIVS表（控制表的权限）和DB_PRIVS 表（控制库的权限）。在开启kerberos之后，传入hive的用户名是principal的全名，比如hdfs/gxxxx@KERBEROS_HADOOP,而hive权限表中的PRINCIPAL_NAME 字段是hdfs,会导致没有表的权限,虽然可以通过update表来更改相应的PRIN...

2017-11-21

645

发表评论

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。