linux卡顿问题排查_记一次星环大数据tdh集群中因某节点systemd服务进程bug而引起大数据集群异常问题的排查与修复...

       某日笔者接到大数据集群使用人员紧急求救，反馈其在用的星环大数据tdh集群遇到以下故障无法解决，影响集群使用无法运行大数据计算任务。其反馈的问题现象如下:

       tdh集群响应慢且不稳定，在transwarp manager server节点(tdh1)节点的管控台页面，可以发现有以下告警：tos运行异常，license运行异常，guardian运行异常；通过tdh管控台页面重启部分服务如inceptor, hdfs时，经常会出现服务重启失败，尝试重启整个tdh集群也会报重启失败。仔细排查某些服务如hdfs,inceptor的状态，有时会发现这些服务在tdh1节点上的角色有报异常，在其他节点的角色则还好。

      笔者接到问题反馈后，首先登陆tdh管控台,观察确认集群使用人员反馈的异常现象，确实如其所述；然后为了进一步排查，登录了tdh1服务器节点，查看服务的状态，服务的具体日志信息和服务器的负载。

   在查看服务状态时 (可以通过命令systemctl status transwarp-manager/transwarp-manager-agent查看)，和查看服务日志时(可以通过命令

kubectl log hadoop-hdfs-namenode-hdfs1-8c8749f94-rfgrp -c hadoop-hdfs-namenode-hdfs1查看)，都发现tdh1节点卡顿严重响应很慢，而tdh2和tdh3则比较顺畅。

    进一步查看服务器负载时，通过free -h 发现tdh1节点占用的内存相比于tdh2和tdh3明显偏高；通过top排查发现tdh1节点的cpu负载很高，而tdh2和tdh3节点则还好，分别如下图所示：

    tdh1节点和tdh3节点free-h结果截图：

tdh1节点和tdh3节点top结果截图：

    为进一步定位问题进程，在top中通过shift + p和shift+m查看占用cpu和memory较高的进程，发现tdh1节点中占用cpu较高的是kswapd0，即swap交换分区对应的进程；而占用内存较高的是systemd进程。进一步谷歌搜索 “systemd consuming too much memory” ，有帖子提到centos7.2前的linux版本中，使用的systemd存在bug: "Memory leak issue in systemd-219-19.el7_2.13.x86_64：Server response is slow due to high memory usage. "top" output shows 'Systemd' daemon is consuming high % memory."。该问题在systemd-219-30以前会有，可以升级centos到更改版本如centos7.3版本或者升级systemd的版本到更改版本比如systemd-219-42.el7_4.7.x86_64就能够解决。

    我们的tdh集群中服务器操作系统版本(可以通过more /etc/redhat-release查看，我们的是CentOS Linux release 7.5.1804 (Core) )和sysemd版本(可以通过yum list installed |grep systemd查看，我们的是systemd-219-67.el7_7.3.x86_64)，并不完全对应上述帖子所述的版本(centos7.2，systemd-219-19.el7_2.13.x86_64)，但systemd进程占用内存异常确认无疑，就是该问题引起的tdh集群卡顿，影响业务使用。由于暂时无法升级服务器操作系统到更高版本，也尽量不想升级systemd版本(怕有其它影响)，笔者首先尝试了使用以下命令释放systemd异常占用的内存：#systemctl daemon-reexec ，但该命令实际执行时似乎并没有释放多少内存，没有解决我们的问题。

    回头来看下集群角色分配，这里明显该tdh集群中各节点角色分配不是很合理，负载并不均衡，因为tdh1是transwarp-manager, 同时又是namenode, resource manager和inceptor server (hive server), 所以其资源占用尤其是内存明显高于其他节点，需要分析个节点的负载情况，迁移部分tdh1节点的角色到其它低负载节点比如tdh3。同时由于以上systemd因bug造成异常占用高内存的问题只有在特定情况下才会出现，且我们的集群是可以重启的，所以笔者决定重启tdh1节点的linux系统，待重启成功且tdh集群响应正常后，分析个节点负载情况，迁移部分tdh1的角色到低负载节点tdh3上。后续如果该集群再频繁遇到这类问题，再进一步谋求集群硬件的升级 (星环官方建议对于功能测试集群，内存要64G以上，CPU要32 核心以上；生产集群内存则要128G以上，cpu核心数要 64以上，而该集群使用的只是8核32G的虚拟机，穷啊。。)。

    接下来的修复过程也是一波三折。首先在通过命令reboot -h now重启服务器时重启失败，经过一番谷歌，通过使用systemctl --force --force reboot重启成功；在迁移 hdfs的namenode进程从tdh1节点到tdh3节点时，配置服务完毕，重新启动hdfs时tdh3节点的namenode启动失败，查看日志/var/log/hdfs1/ hadoop-hdfs-namenode-tdh-03.log,发现以下关键报错信息：2020-12-11 14:22:43,217 ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: Error encountered requiring NN shutdown. Shutting down immediately. java.io.IOException: java.io.IOException: Cannot start namenode because current license does notcontain the serverkey of this node!

at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startLicenseClusterServices (FSNamesystemjav:1337) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startStandbyServices (Namenode.java:1740)

    仔细观察该异常日志，其核心意思是说，当前集群使用的licence不包含该namenode节点的serverKey。联想到星环一贯通过licence对集群使用情况的管控，不难联想到这是星环通过修改hdfs源码，限定了集群的使用。事实上，tdh集群中会根据集群namenode节点的mac地址生成对应的serverkey，然后该serverkey会绑定到集群使用的licence，当namenode节点迁移后，基于新的namenode节点的mac地址会生成一个新的不同于原来的serverkey，该serverKey跟集群原来使用的licence没有绑定关系，当启动namenode时会检测serverkey与licence的绑定关系，由于检测不到造成了启动失败！通过以上报错是的异常堆栈信息，对比开源的hdfs的源码，不难猜到星环修改的是类org.apache.hadoop.hdfs.server.namenode.FSNamesystem的源码，在startStandbyServices()方法中增加调用了一个自己编写的方法startLicenseClusterServices()，来做上述serverKey与licence绑定关系的校验)。

    所以接下来我们联系了星环客服，说明了情况并告知了新的serverkey信息，申请了一个新的licence。在申请到对应新的server key的license后，配置hdfs服务后，重启hdfs成功；然后着手对

inceptor server迁移，通过在tdh3节点添加inceptor server角色，然后停止并删除tdh1节点的inceptor server角色，然后配置inceptor服务后，重启inceptor成功，整个集群重启成功。(inceptor server的迁移，不会遇到启动问题，星环只对hdfs的namenode的硬件mac地址和licence做了捆绑)

    在迁移了tdh1节点的hdfs的namenode和inceptor server角色到tdh3节点后，top和free未见任何异常，执行上述systemctl, kubectl等命令也很顺畅，同是整个tdh集群监控未见任何异常，大数据作业运行也顺畅多了，问题完美解决！