记一次HDFS性能问题排查

问题表现

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

问题分析

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

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

网络、内存都没问题，那就是CPU和I/O了，这两个使用 top和 iostat就可以了，一看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++），最后使用大师教我最笨的二分法定位出来了， 有时候最笨的方法，可能是最有效的方法。

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