本文主要阐述大数据平台环境zookeeper常见异常和解决方案

1.Connection reset by peer异常

• 异常说明

我们现在项目有个任务OneMinuteDataSync是用spark将实时数据同步插入到hbase中，程序已经稳定运行很长一段时间，不过最近数据量增加比较多，任务运行一段时间后，突然僵死几个小时后，有恢复正常继续运行，如下图，任务正常运行情况下耗时15s左右，但2017-07-11 04:33:00这个批次运行了9486s,而凌晨数据量很少的，才13w左右，白天峰值稳定在45w左右。

查看该任务的运行的worker节点的日志，发现zoookeeper connection reset by peer异常日志

• 解决方案

首先查询zookeeper日志，只发现了Too many connectionn 警告

由于刚开始的时候zookeeper zoo.cfg没有配置maxClientCnxns参数，而zookeeper默认配置为60，即单个客户端与单台服务器之间的连接数的限制，而我们前几天才升级hbase和zookeeper集群，已经将

maxClientCnxns=300

 而对于单台服务器来说，300个连接我们认为已经足够使用。我们在30.27.96.14上查看2181端口的连接情况

netstat -anp | grep 2181netstat -anp | grep 2181 | wc

发现实际上状态为ESTABLISHED的连接只有不到10个，而状态为TIME_WAIT的连接有几百个，而TIME_WAIT状态实际上是客户端建立连接，完成任务后正常断开连接后的状态，其他状态解释如下：

CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉

更加详细的内容要去阅读TCP协议。而我们现在要解决的是连接正常关闭后，尽快减少TIME_WAIT状态的连接，最后我们通过修改Linux内核参数来减少服务器的TIME_WAIT套接字数量，步骤如下：

#1.切换到root用户su root#2.更改sysctl.conf配置，增加如下两行配置vi /etc/sysctl.confnet.ipv4.tcp_tw_reuse=1##表示开启重用。允许将TIME_WAIT套接字重新用于新的TCP连接。默认为0，表示关闭。net.ipv4.tcp_tw_recycle=1##表示开启TCP连接中TIME_WAIT套接字的快速回收。默认为0，表示关闭#3.让配置立即生效 /sbin/sysctl -p

更改spark集群服务器配置后，目前程序运行正常，后续继续观察。

大数据平台常见异常-zookeeper