CentOS6上Hadoop集群中服务器cpu sys态异常的定位与解决

简介: 问题现象 在zabbix系统中,对Hadoop集群的历史监控数据分析时,发现在执行大Job任务时,某些服务节点的cpu sys态很高; 具体以hadoop_A服务节点为例,在10:15-10:40这个时间段,cpu user态为60%,而sys态则高达35%; 对于整个Hadoop集群,并不是所有的节点都会出现sys过高的问题,产生此类问题的都是部署CentOS6系统的节点。

问题现象

  1. 在zabbix系统中,对Hadoop集群的历史监控数据分析时,发现在执行大Job任务时,某些服务节点的cpu sys态很高;
  2. 具体以hadoop_A服务节点为例,在10:15-10:40这个时间段,cpu user态为60%,而sys态则高达35%;
  3. 对于整个Hadoop集群,并不是所有的节点都会出现sys过高的问题,产生此类问题的都是部署CentOS6系统的节点。

定位分析

  1. 根据zabbix系统中cpu sys很高的问题发生时间,找到触发问题的大Job,以便于后面的问题重现和问题验证;
  2. 对问题节点hadoop_A的硬件信息和OS系统日志/var/log/messages进行初步检查,并未发现异常;
  3. 重启Job,重现问题。并使用nmon工具对问题节点hadoop_A的资源负载进行粗粒度的实时监测;
    hadoop_A节点上某一时刻瞬时的负载状态如下图:
    Alt text
  4. 通过上图,注意到网络流量达到了119.7MB/s,接收和发送的峰值都超过了120MB/s,初步怀疑网口在某一时间成为瓶颈,导致内核的sys过高。对hadoop_A的网口计数器细化分析,系统在uptime了83天的状态下,网口计数器中除overruns指标达22万之外,其他的网络指标正常。 这说明网络确实曾达到过峰值,也丢过包,但频率非常低,sys过高的问题应该不是网络负载过高触发。
    ifconfig查询网口的计数器状态如下图:
    Alt text
  5. 需要对系统进行更细粒度的分析,找出系统sys态消耗在什么地方。在hadoop_A节点上部署perf工具,通过perf top对kernel事件采样,实时分析内核事件。
    perf top在某一时刻的状态图如下:
    Alt text
    通过perf top监控可以断定:kernel中存在频繁的spin_lock_irqsave内核系统调用, sys态消耗过高应该与此有关。
  6. 重启Job,再次重现问题,并利用perf工具对内核函数的调用关系采样:
    perf record -a -g -F 1000 sleep 30
    采样结束后,在当前目录上会生成一个perf.data文件,使用perf工具查看函数调用关系:
    perf report -g
    perf report查看到的调用关系如下图:
    Alt text
  7. 通过调用依赖关系分析,spin_lock_irqsave主要called by compaction_alloc,初步推测问题由kernel的内存管理部分触发。联想到centos 6相对于centos 5在kernel内存管理模块的一些改进点(如transparent huge page, 基于numa的内存分配等),有没有可能是CentOS6新增的THP特性导致cpu sys过高?再在google上搜一把相关函数名的关键字,印证这个猜测。

问题验证

  1. 选择在节点hadoop_A上面做验证测试,通过以下内核参数优化关闭系统THP特性:
     echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag 

  2. 重启触发问题的大Job,在hadoop_A节点未出现cpu sys 状态过高的现象。
  3. 在生产系统上运行24小时后,通过zabbix系统观察,其他内核未优化节点如hadoop_B,hadoop_C等节点依然存在cpu sys态过高的问题,而关闭了THP特性的hadoop_A节点没有出现cpu sys态过高的问题,验证了之前的分析。
    hadoop_B和hadoop_C依然存在cpu sys态过高的问题:
    Alt text
    hadoop_A cpu sys态正常:
    Alt text

结论

将Hadoop集群中所有CentOS6类型节点的THP特性关闭掉(在CentOS6中,THP特性默认都是打开的),关闭方法如下:


 echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag 

值得注意的是,需要在puppet系统中部署该项优化,以免节点重启导致修改丢失。

参考

事后,在redhat官网和cloudera官网也搜到了相关的内容,附录下来,供参考。

  1. 在redhat的官网上,有对THP特性的细化说明:
    https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-transhuge.html
  2. 在cloudera的CDH4部署说明中,也建议将系统的THP的compaction特性关闭:
    http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/4.2.2/CDH4-Installation-Guide/cdh4ig_topic_11_6.html



转: http://tech.meituan.com/cpu_sys_high_in_hadoop_cluster.html

目录
相关文章
|
2月前
|
弹性计算 网络安全 数据安全/隐私保护
ECS热门应用 | 解决Guestosssh异常
通过ECS实例快速发现操作系统内部的问题,并给出对应的修复方案。
129296 5
|
2月前
|
缓存 关系型数据库 MySQL
百度搜索:蓝易云【CentOS8服务器安装MySQL报错:no match mysql-community-server】
现在,你已经成功安装了MySQL服务器并解决了"no match mysql-community-server"的报错问题。祝你使用愉快!
40 1
|
3月前
|
Linux
CentOS7.9服务器一键脚本部署FRP内网穿透服务端与客户端
CentOS7.9服务器一键脚本部署FRP内网穿透服务端与客户端
201 0
|
3月前
|
Linux 网络安全
CentOS7服务器SSH登陆时自动显示服务器基础信息
CentOS7服务器SSH登陆时自动显示服务器基础信息
38 0
|
4月前
|
存储 Linux 虚拟化
CentOS 7搭建NFS服务器
CentOS 7搭建NFS服务器
104 0
|
24天前
|
存储 数据挖掘 Windows
服务器数据恢复—异常断电导致raid信息丢失的数据恢复案例
由于机房多次断电导致一台服务器中raid阵列信息丢失。该阵列中存放的是文档,上层安装的是Windows server操作系统,没有配置ups。 因为服务器异常断电重启后,raid阵列可以正常使用,所以未引起管理员的注意。后续出现的多次异常断电导致raid报错,服务器无法找到存储设备,进入raid管理模块进行任何操作都会导致操作系统死机。管理员尝试多次重启服务器,故障依旧。
|
30天前
|
Oracle 关系型数据库 Linux
服务器Centos7 静默安装Oracle Database 12.2
服务器Centos7 静默安装Oracle Database 12.2
66 0
|
1月前
|
存储 弹性计算 Linux
阿里云ECS(CentOS镜像)安装docker
阿里云ECS(CentOS镜像)安装docker
367 0
|
2月前
|
数据挖掘 数据库 虚拟化
服务器数据恢复-异常断电导致服务器数据丢失的数据恢复案例
服务器数据恢复环境: dell某型号服务器中有一组通过raid卡组建的raid10,该raid阵列中一共有4块磁盘。上层部署XenServer虚拟化平台,作为网站服务器使用。 服务器故障: 服务器异常断电导致服务器上的一台虚拟机不可用。需要恢复这台虚拟机上的数据库数据。
服务器数据恢复-异常断电导致服务器数据丢失的数据恢复案例
|
2月前
|
弹性计算 监控 Linux
ECS实例问题之负载异常如何解决
ECS实例指的是在阿里云ECS服务中创建的虚拟计算环境,用户可在此环境中运行应用程序和服务;本合集将介绍ECS实例的创建、管理、监控和维护流程,及常见问题处理方法,助力用户保障实例的稳定运行。

热门文章

最新文章