记一次HDFS性能问题排查

标签: geek | 发表时间:2018-02-21 00:00 | 作者:
出处:http://itindex.net/relian

问题表现

HDFS刚上线没有任何问题。就最近现网读写HDFS时,阶段性比较慢,也不是一直都比较慢,慢的时候读取一次需要20秒左右,一般毫秒级就可以返回。

问题分析

慢一次后,紧接着就快。这种表现第一印象就是JVM GC导致的吧。那我就使用jstat进行分析。运行 jstat -gcutil [pid] [<interval> [<count>]],(悲哀啊,伟大的华为不让内网对外发布文章,这篇文章只能在家里写,就不可以图文并茂了,sorry),发现每次fullGC都不会超过秒,都是毫秒级。天呢,看来不是JVM GC导致的,此次猜想失败,问题陷入僵局。

总不能坐以待毙吧,那是不是网络问题呢?qperf出场,qperf的更多使用,可以参考 网络性能测试工具qperf使用。网络没有发现任何问题,网络也排查在外。

网络、内存都没问题,那就是CPU和I/O了,这两个使用 topiostat就可以了,一看CPU和I/O负载都比较低。 问题白热化了

看来通过简单的非注入工具问题是解决不了了。问题可复现,这很重要啊,那我就只能自己写个读程序,通过注入性工具查看。

注入性工具,性能问题第一想到的就是strace,查看一下系统调用,时间到底耗在哪儿了。strace的简单使用实例如下:

   strace -o sshd.strace -fT -p 5352
strace -o ssh.strace -fT ssh 10.71.171.142

在文件中打印出来的系统调用比较多,虽然只是一个简单的数据读取。因为最后一列是时间,那么我就从一秒到十秒搜索一下吧,最后就发现了一个频繁5秒的调用,当前是timeout。那么通过上下文,发现前面有多次sendto进行重试,内容尽然是hadoop.hadoop.com,这让我想起了kerberos认证,kerberos认证中使用了这个域名,猜想应该是域名解析比较慢。 nslookup hadoop.hadoop.com确实比较慢,应该达到了几秒。为什么需要解析 hadoop.hadoop.com这个域名呢?认证的时候使用了user/ [email protected],不应该解析才对啊。暂时没时间知道原因,先解决问题,后面再了解原因。域名解析的大致步骤是 hosts->本地的域名服务器->指向的外面的域名服务器。那我们就在hosts中先加hadoop.hadoop.com域名吧。重启进程果然解决。

问题根因

  • 那为啥要对hadoop.hadoop.com进行解析呢?

在kerberos官网找到了如下的解释:

服务管理员经常发布希望用户使用的主机名别名,而不是服务主机的规范名称。 这为服务管理员提供了部署服务的更多灵活性。 例如,一个shell登录服务器可能被命名为 “long-vanity-hostname.example.com”,但用户自然会喜欢类似 “login.example.com”。 MIT Kerberos客户端目前总是执行解析域名和反向解析以规范主机名。参考 Principal names and DNS

  • 那为啥现在突然域名解析服务有问题了呢?

原来新增一个服务,为了使用公有云的服务,本地域名服务不可以解析的转向了公有云的域名服务,公有云的域名解析服务有问题,但是推不动(大公司就这个熊样),也只能通过hosts解决了。终极解决方法应该设置域名解析服务的反向解析。
http://www.ttlsa.com/linux/resolv-conf-desc/

问题总结

虽然走了一些弯路,但上面也体现了定位问题的一些通用方法,也不至于无从下手。如果谁有更好的 问题定位工具或方法也欢迎交流,我记得刚毕业的时候,还定位过一次内存泄漏(C/C++),最后使用大师教我最笨的二分法定位出来了, 有时候最笨的方法,可能是最有效的方法

程序员最开心的就是发现问题,然后通过自己努力解决问题,把自己挖的坑和别人挖的坑(心里默默骂一句)一个个填好。

相关 [hdfs 性能 问题] 推荐:

记一次HDFS性能问题排查

- - IT瘾-geek
就最近现网读写HDFS时,阶段性比较慢,也不是一直都比较慢,慢的时候读取一次需要20秒左右,一般毫秒级就可以返回. 这种表现第一印象就是JVM GC导致的吧. jstat -gcutil [pid] [ []],(悲哀啊,伟大的华为不让内网对外发布文章,这篇文章只能在家里写,就不可以图文并茂了,sorry),发现每次fullGC都不会超过秒,都是毫秒级.

HDFS-压缩

- - Java - 编程语言 - ITeye博客
文件压缩带来了两大益处1)减少存贮空间2)加速网络(磁盘)传输. 基于大数据的传输,都需要经过压缩处理. 压缩格式 工具 算法 文件扩展名 可分块. Java代码 复制代码 收藏代码. 24.        // io.compression.codecs 定义列表中的一个 . Native gzip 库减少解压缩时间在50%,压缩时间在10%(同java实现的压缩算法).

HDFS架构

- - 数据库 - ITeye博客
       在阅读了GFS的论文之后,对GFS的框架有了基本的了解,进一步学习自然是对HDFS的解析,不得不说,之前对GFS的一些了解,对理解HDFS还是很有帮助的,毕竟后者是建立在前者之上的分布式文件系统,二者在框架上可以找到很多的共同点,建议初次接触HFDS的技术人员可以先把GFS的那篇论文啃个两三遍,毕竟磨刀不砍柴工.

Hadoop剖析之HDFS

- - CSDN博客数据库推荐文章
Hadoop的分布式文件系统(HDFS)是Hadoop的很重要的一部分,本文先简单介绍HDFS的几个特点,然后再分析背后的原理,即怎样实现这种特点的. 这是HDFS最核心的特性了,把大量数据部署在便宜的硬件上,即使其中某些磁盘出现故障,HDFS也能很快恢复丢失的数据. 这个的意思是HDFS适合一次写入,多次读取的程序,文件写入后,就不需要修改了.

Exception性能问题

- - 非技术 - ITeye博客
   1.从Exception往上介绍相关结构、代码.     class Exception里面没有什么新鲜东西,它继承自class Throwable,接下来我们看一下Throwable的结构,在它的构造函数中调用了fillInStackTrace这个函数. 接下来我们看看这个函数干了些什么.     fillInStackTrace函数的声明为.

Hoop:Hadoop HDFS的RESTFul封装

- Vent - NoSQLFan
Hoop是对Hadoop HDFS Proxy 的改良重写,为Hadoop HDFS提供了HTTP(S)的访问接口. 通过标准的HTTP协议访问你的HDFS系统. 在运行不同版本的HDFS之间进行数据交换(这克服了一些RPC方式因版本不同而产生的兼容性问题). 将对HDFS的操作置于防火墙的保护下.

[转]HDFS用户指南

- - 小鸥的博客
本文档可以作为使用Hadoop分布式文件系统用户的起点,无论是将HDFS应用在一个Hadoop集群中还是作为一个单独的分布式文件系统使用. HDFS被设计成可以马上在许多环境中工作起来,那么一些HDFS的运行知识肯定能大大地帮助你对一个集群做配置改进和诊断. HDFS是Hadoop应用的主要分布式存储.

HDFS 读文件分析

- - 经验沉淀 知识结晶
UNIX Domain Socket是在socket架构上发展起来的用于同一台主机的进程间通讯(IPC),它不需要经过网络协议栈,不需要打包拆包、计算校验和、维护序号和 应答等,只是将应用层数据从一个进程拷贝到另一个进程. UNIX Domain Socket有SOCK_DGRAM或SOCK_STREAM两种工作模式,类似于UDP和TCP,但是面向消息的UNIX Domain Socket也是可靠的,消息既不会丢失也不会顺序错乱.

Hadoop之HDFS子框架

- - CSDN博客云计算推荐文章
由图片可以看到HDFS主要包含这样几个功能组件. Namenode:存储文档的元数据信息,还有整个文件系统的目录结构. DataNode:存储文档块信息,并且文档块之间是有冗余备份的. 这里面提到了文档块的概念,同本地文件系统一样,HDFS也是按块存储的,只不过块的大小设置的相对大一些,默认为64M.

hdfs-ha热备原理

- - 开源软件 - ITeye博客
下面的总结来自于: http://dongxicheng.org/hadoop-hdfs/hdfs-ha-federation-deploy/ .            Hadoop 2.0中的HDFS增加了两个重大特性,HA和Federaion. HA即为High Availability,用于解决NameNode单点故障问题,该特性通过热备的方式为主NameNode提供一个备用者,一旦主NameNode出现故障,可以迅速切换至备NameNode,从而实现不间断对外提供服务.