记一次Hive任务hang住的问题(2)

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次Hive任务hang住的问题(2)相关的知识,希望对你有一定的参考价值。

参考技术A 线上Hive任务偶尔出现hang住的现象.
经排查确认是触发了Hive的bug, 该bug在Hive-10569( https://issues.apache.org/jira/browse/HIVE-10569 中已修复.

用户beeline任务运行至Ended Job之后,一直未结束,查看yarn日志,该job已经运行成功.

找到该job在hive server端的日志,没有发现任何异常.

分别通过 jstack -l <pid> 和 jmap -dump:[live,]format=b,file=<filename> <pid> 获取server端的堆栈信息.

本案例中线程栈如下:

查看源码位置, 分析可知runner.isRunning状态未更新会导致hang住不结束.

查找社区issue发现, 该bug已经在1.3版本中进行了修复.( https://issues.apache.org/jira/browse/HIVE-10569
后续 backport 该patch即可.

OGG目标端复制Sequence时Hang住的问题

昨天遇到一个问题一个OGG的复制进程在复制序列(Sequence)时Hang住不动,进程状态一直是Running状态但是不往前进行复制,导致进程延迟6个多小时

GGSCI (ctm-3) 2> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING                                           
REPLICAT    RUNNING     USIM        00:13:39      06:50:22

操作复制进程时,stats和stop显示操作超时,只能kill进程,重启复制进程问题依就。问题从下午一直持续到晚上7点多,实在没有办法把所有数据都全部初始化了,还是不行,好在数据量不大。最后把goldengate用户赋予dba权限问题就解决了,但是GOLDENGATE用户的权限分配问题依然还是一个问题。下面记录了问题的处理过程,有兴趣的朋友可以看看。

使用view report usim查看日志,日志停在一个复制Sequence的语句上

Wildcard MAP resolved (entry USIM.*):
  map "USIM"."SEQ_PROCESSSTEP", target USIM."SEQ_PROCESSSTEP";
Resolving target sequence USIM.SEQ_PROCESSSTEP.

查看ggserr.log也没有报错信息。

于是查看数据库里的会话

[email protected]> select sid,serial#,LOGON_TIME,MODULE,sql_id,prev_sql_id,event,blocking_session from v$session where MODULE like ‘%USIM%‘;

       SID    SERIAL# LOGON_TIME   MODULE                         SQL_ID        PREV_SQL_ID   EVENT                          BLOCKING_SESSION
---------- ---------- ------------ ------------------------------ ------------- ------------- ------------------------------ ----------------
       764       8229 20-JAN-17    OGG-USIM-OPEN_DATA_SOURCE      awjuqsu6bk5d4 b6zg67dtg1q14 row cache lock
       
[email protected]> select sql_text from v$sql where sql_id=‘awjuqsu6bk5d4‘;

SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT "SEQ_PROCESSSTEP".NEXTVAL FROM DUAL

[email protected]> select sql_text from v$sql where sql_id=‘b6zg67dtg1q14‘;

SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT HIGHWATER FROM SYS.SEQ$ WHERE OBJ#=:B1

看到当前ogg的复制进程在执行SELECT "SEQ_PROCESSSTEP".NEXTVAL FROM DUAL的语句,进程是在等待row cache lock。上面贴出来的是晚上查询时的情况,其实下午在查这条sql时是不同的一个序列名字,但是动作一样都是select nextval from dual,但是等待事件有library cache: mutex X、cursor: pin S wait on X、latch free、latch: shared pool。

看到这些等待事件头都大了,先到百度上去搜索,看到有帖子说有可能是BUG,然后又到MOS上去搜等待事件的组合,看到很多BUG的文章,但是描述跟现在遇到的情况不一致。于是又转到搜goldengate和序列hang的关键字,搜到一篇http://m.blog.csdn.net/article/details?id=48544207,在MOS上搜到1331998.1和1535322.1,但都是跟现在的情况不符。

于是又无奈的去查官方文档,在Oracle GoldenGate Oracle Installation and Setup Guide中查到下面的几句话:

技术分享

看到红框中的那句后恍然想到,由于系统交维,要求不允许用户有DBA角色,GOLDENGATE也不可以,于是查看GOLDENGATE用户的角色

[email protected]> select granted_role from dba_role_privs where grantee=‘GOLDENGATE‘;

GRANTED_ROLE
------------------------------
RESOURCE
CONNECT
SELECT_CATALOG_ROLE

果然没有DBA角色,那问题是不是出在这里呢,于是尝试给GOLDENGATE用户DBA角色

grant dba to goldengate;

kill掉hang住的会话,重启复制进程usim,终于问题解决了。复制进程开始往下复制了,而且序列复制的很快

GGSCI (ctrm-r3) 20> stats usim hourly

Sending STATS request to REPLICAT USIM ...

Start of Statistics at 2017-01-20 21:47:22.

DDL replication statistics:

*** Total statistics since replicat started     ***
        Operations                                         0.00
        Mapped operations                                  0.00
        Unmapped operations                                0.00
        Other operations                                   0.00
        Excluded operations                                0.00
        Errors                                             0.00
        Retried errors                                     0.00
        Discarded errors                                   0.00
        Ignored errors                                     0.00

Replicating from USIM.SEQ_PROCESSSTEP to USIM.SEQ_PROCESSSTEP:

*** Hourly statistics since 2017-01-20 21:46:06 ***
        Total updates                                     16.00
        Total discards                                     0.00
        Total operations                                  16.00

End of Statistics.

最后再回想,难道就真的是因为DBA角色的关系么?于是把GOLDENGATE用户的DBA角色收回:revoke dba from goldengate;

再次观察复制进程情况,竟然正常在复制,没有受到影响。而且从昨晚10点多回收dba角色,到今天发博客,复制进程也没有hang住,还在正常复制。这就回到了上面疑问,真的是因为DBA角色导致的么?现在还不清楚。如果哪位大神知道问题的原因可以在博客中回复,感激不尽。

本文出自 “DBA Fighting!” 博客,请务必保留此出处http://hbxztc.blog.51cto.com/1587495/1893514

以上是关于记一次Hive任务hang住的问题(2)的主要内容,如果未能解决你的问题,请参考以下文章

Flink使用——记一次Flink Session任务反复重启

记一次定时任务没有执行的原因

记一次Laravel定时任务导致日志没有写入权限的坑

记一次Laravel 定时任务schedul:run未执行的处理

记一次storm提交任务遇到的坑

记一次Quartz重复调度(任务重复执行)的问题排查