Spark ERROR: org.apache.spark.shuffle.FetchFailedException 问题追查_org.apache.spark.storage.shuffleblockfetcheriterat-CSDN博客

本文链接：https://blog.csdn.net/xwc35047/article/details/78771148

本文详细记录了在升级到Spark 2.2.1 thriftserver服务后，遇到的task高失败率问题，特别是FetchFailedException错误。通过对错误日志的深入分析，发现并非由于资源竞争导致，而是与网络连接失败有关。具体表现为无法连接到指定的IP地址和端口，引发IOException。解决方案可能涉及检查网络连接、shuffle服务配置以及排查集群间通信问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

####背景
因为这两天升级上线spark 2.2.1 thriftserver服务，对服务运行情况，尤其对失败作业的关注比较高，今天发现有一台机器上的task失败率格外高，报错FetchFailedException，过去我会认为是资源竞争，导致executor因内存不足而挂掉，从而导致block fetch失败。今天仔细一查，发现问题的另一个原因。

下面是追查过程：

####1）首先看到spark web显示报错：
这里写图片描述

FetchFailed(BlockManagerId(149, hadoop848.bx.com, 11681, None), shuffleId=135, mapId=12, reduceId=154, message=
org.apache.spark.shuffle.FetchFailedException: Failed to connect to hadoop848.bx.com/10.88.69.188:11681
at org.apache.spark.storage.ShuffleBlockFetcherIterator.throwFetchFailedException(ShuffleBlockFetcherIterator.scala:513)
at


####2） 然后进入stderr页面观察task 日志情况：
![这里写图片描述](https://img-blog.csdn.net/20171211115653128?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveHdjMzUwNDc=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)

17/12/11 11:42:02 ERROR RetryingBlockFetcher: Exception while beginning fetch of 6 outstanding blocks (after 1 retries)
java.io.IOException: Failed to connect to hadoop972.bx.com/10.87.112.82:15733
at org.apache.spark.network.client.TransportClientFactory.createClient(TransportClientFactory.java:232)
at org.apache.spark.network.client.TransportClientFactory.createClient(TransportClientFactory.java:182)
at org.apache.spark.network.netty.NettyBlockTransferService$$anon $1 . c r e a t e A n d S t a r t (N e t t y B l o c k T r a n s f e r S e r v i c e . s c a l a : 97) a t o r g . a p a c h e . s p a r k . n e t w o r k . s h u f f l e . R e t r y i n g B l o c k F e t c h e r . f e t c h A l l O u t s t a n d i n g (R e t r y i n g B l o c k F e t c h e r . j a v a : 141) a t o r g . a p a c h e . s p a r k . n e t w o r k . s h u f f l e . R e t r y i n g B l o c k F e t c h e r . l a m b d a$ initiateRetry $0 (R e t r y i n g B l o c k F e t c h e r . j a v a : 169) a t j a v a . u t i l . c o n c u r r e n t . E x e c u t o r s$ RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor $W o r k e r . r u n (T h r e a d P o o l E x e c u t o r . j a v a : 617) a t i o . n e t t y . u t i l . c o n c u r r e n t . D e f a u l t T h r e a d F a c t o r y$ DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:745)
Caused by: io.netty.channel.AbstractChannel $A n n o t a t e d C o n n e c t E x c e p t i o n : C o n n e c t i o n t i m e d o u t : h a d o o p 972 . b x . c o m / 10.87.112.82 : 15733 a t s u n . n i o . c h . S o c k e t C h a n n e l I m p l . c h e c k C o n n e c t (N a t i v e M e t h o d) a t s u n . n i o . c h . S o c k e t C h a n n e l I m p l . f i n i s h C o n n e c t (S o c k e t C h a n n e l I m p l . j a v a : 717) a t i o . n e t t y . c h a n n e l . s o c k e t . n i o . N i o S o c k e t C h a n n e l . d o F i n i s h C o n n e c t (N i o S o c k e t C h a n n e l . j a v a : 257) a t i o . n e t t y . c h a n n e l . n i o . A b s t r a c t N i o C h a n n e l$ AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:291)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:631)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:566)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:480)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:442)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(Sing

日志的重点是连接超时，而且重试多次仍然超时。

####3）登入到hadoop244.bx，使用top观察进程资源占用情况
![这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcxMjExMTE0OTE2ODQz?x-oss-process=image/format,png)
 发现有一个PID为95479的进程cpu占用一直超过100%

####4）然后jps查看进程情况
![这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcxMjExMTE1MjQ1MzQy?x-oss-process=image/format,png)
然后发现，PID 95479 对应是一个tez作业，这个作业长期占用大量cpu资源，导致其他进程（如当前场景的spark进程）获取执行时间要等待很长，从而导致连接timeout，导致spark作业失败。

**总结： 有必要让yarn采用类似cgroup的资源限制功能，限制单个进程对资源的长期占用，避免异常对其他作业的影响；同时加大timeout超时时间，提高对计算及网络环境不好情况下的鲁棒性。**

**文章会同步到公众号，关注公众号，交流更方便：**
![在这里插入图片描述](https://img-blog.csdnimg.cn/2019090815181861.jpg)