公司的一个Hadoop集群，集群的每个节点都部署了一个agent,可以从另外一台管理机去访问各个Hadoop节点的agent服务，去获取节点信息和做一个节点管理操作。最近发现了一个问题，同事反馈从管理去请求Hadoop节点的agent很异常，有很多会请求超时，同时，同事也反馈了另外一个情况， 如果从管理机ssh到集群节点，执行一下操作，经常会造成终端卡死，无法响应。
晚上下班回家，连上vpn,就去看了看，首先是去重现终端卡死的问题。ssh登陆到集群的一个节点后，执行ls命令等是正常的，但是vim打开一个不到10M的日志文件，然后终端就卡死，没有反应了，很是奇怪，后来我就又打开了一个终端，ssh连接到同一个台机器， netstat看了一下22端口的状态，发现了一个很奇怪的现象,发现有个established状态的连接的SEND-Q堵包了，而且在不断增长，感觉这里肯定是有问题的了。
这让我联想起之前碰到的一个问题：之前我从一台客户端去请求一个服务端的API获取一个列表，当数据集很小的时候，请求ok,当数据集稍微大一点儿就会请求超时，最后排查下来，发现是机器mtu的问题， 把机器的mtu调小一些就好了。 这次会不会也是同样的问题呢，为了验证这个猜想，我又在之前的Hadoop节点做了测试，当vim打开一些小文件的时候，终端是正常的，不会卡死，当vim打开的文件稍微大一些，就会卡死，似乎和之前遇到的情况是类似的。ifconfig去看了管理机网卡的的mtu是1500， 又去看了Hadoop节点的mtu，也是1500，又让我迷惑了，这个时候已经是夜里一点多了。。。随后，我下意识地去看了另外一个访问正常的Hadoop集群，令人兴奋的事情出现了，我发现这个节点上的mtu是1454，我想我大概知道问题了，果然还是mtu的问题。
ssh连到之前vim打开文件会卡死的Hadoop节点，先临时将网卡的mtu改小：
1 | ifconfig eth2 mtu 1454 up |
果然， 之后无论我在终端里面怎么折腾，vim打开多大的文件，都不会出现卡死了。
那为什么管理机和目标机器的mtu 都是1500，还会出现这种情况呢？应该是中间网路设备的锅了， 估计中间有路由设备的mtu值小于1500的原因了。
修改了mtu之后，netstat之后也没有看到发包堵塞的情况了， 管理机访问Hadoop节点的agent服务也正常的，问题搞定,睡觉～