reduce代码会随机卡住

dsf9zpds  于 2021-05-29  发布在  Hadoop
关注(0)|答案(2)|浏览(310)

我们有一个用java编写的map reduce代码,它读取多个小文件(比如10k+)并在驱动程序中将其转换为单个avro文件,reducer将一组简化的记录插入postgres数据库。这个过程每小时都会发生。但是有多个map reduce作业同时运行,处理不同的avro文件,并为每个作业打开不同的数据库连接。所以有时(非常随机)所有的任务都会陷入缩减阶段,除了以下例外-

"C2 CompilerThread0" daemon prio=10 tid=0x00007f78701ae000 nid=0x6db5 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00007f78701ab800 nid=0x6db4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Surrogate Locker Thread (Concurrent GC)" daemon prio=10 tid=0x00007f78701a1800 nid=0x6db3 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x00007f787018a800 nid=0x6db2 in Object.wait() [0x00007f7847941000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006e5d34418> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
    - locked <0x00000006e5d34418> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)

"Reference Handler" daemon prio=10 tid=0x00007f7870181000 nid=0x6db1 in Object.wait() [0x00007f7847a42000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006e5d32b50> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:503)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
    - locked <0x00000006e5d32b50> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x00007f7870013800 nid=0x6da1 runnable [0x00007f7877a7b000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:152)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:143)
    at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:112)
    at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:71)
    at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:269)
    at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1700)
    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
    - locked <0x00000006e5d34520> (a org.postgresql.core.v3.QueryExecutorImpl)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:417)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:302)
    at ComputeReducer.setup(ComputeReducer.java:299)
    at org.apache.hadoop.mapreduce.Reducer.run(Reducer.java:162)
    at org.apache.hadoop.mapred.ReduceTask.runNewReducer(ReduceTask.java:610)
    at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:444)
    at org.apache.hadoop.mapred.Child$4.run(Child.java:268)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:415)
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1438)
    at org.apache.hadoop.mapred.Child.main(Child.java:262)

"VM Thread" prio=10 tid=0x00007f787017e800 nid=0x6db0 runnable 

"Gang worker#0 (Parallel GC Threads)" prio=10 tid=0x00007f7870024800 nid=0x6da2 runnable 

"Gang worker#1 (Parallel GC Threads)" prio=10 tid=0x00007f7870026800 nid=0x6da3 runnable

在这个异常发生后,我们必须重新启动数据库,否则所有reduce作业都会被闲置70%左右,甚至下一个小时的作业也无法运行。最初,它用于排出打开连接的数量,但在将连接增加到相当高的数量后,情况并非如此。我应该指出,我不是数据库Maven,所以请建议任何可能有帮助的配置更改。只是为了确认这似乎是数据库配置问题吗?如果是,那么在postgres上配置连接池有助于解决这个问题吗?
如有任何帮助/建议,我们将不胜感激!提前谢谢。

50few1ms

50few1ms1#

我想补充一下我的发现,在重构代码后,它运行了好几个月,然后这个问题再次出现,我们认为这是一个hadoop集群问题,所以创建了一个新的hadoop集群,但这也没有解决问题。最后,我们查看了最大的数据库表,它有超过15亿行,select query需要花费大量时间,因此在从该表中删除旧数据之后,full vacuum和reindex起到了帮助作用。

3z6pesqy

3z6pesqy2#

我最初的想法是,如果它是随机的,它可能是一个锁。有两个区域可以查找锁:
共享资源上的线程之间的锁和数据库对象上的锁。
我在堆栈跟踪中没有看到任何迹象表明这是一个数据库锁问题,但这可能是由于没有关闭事务导致的,因此不会出现死锁,但您正在等待插入。
更有可能是java代码中出现死锁,可能是两个等待的线程在互相等待?

相关问题