TPCDS-Hive-testbench运行报错status-139的解决方法

1,683次阅读
没有评论

共计 1300 个字符,预计需要花费 4 分钟才能阅读完成。

背景

前阵子在用 Tpcds 对 hive 做性能测试的时候,遇到过报错 Process failed with status code 139

问题剖析

通过源码查看,找到了最终异常抛出的地方:hive-testbench-hdp3/tpcds-gen/src/main/java/org/notmysock/tpcds/GenTable.java

源码 github 地址

    for(int i=0; i<cmd.length; i++) {if(cmd[i].equals("$DIR")) {
        // 这里的相对路径 . 即 container 运行的目录
        cmd[i] = (new File(".")).getAbsolutePath();}
        if(cmd[i].equals("-parallel")) {parallel = cmd[i+1];
        }
        if(cmd[i].equals("-child")) {child = cmd[i+1];
        }
    }


    Process p = Runtime.getRuntime().exec(cmd, null, new File("dsdgen/tools/"));
    int status = p.waitFor();
    if(status != 0) {String err = readToString(p.getErrorStream());
        // 这里是错误抛出的地方,可以看到报错原因就是提示上面的路径过长。throw new InterruptedException("Process failed with status code" + status + "\n" + err);
    }
  • 根据报错码 139 查询 p.waitFor() 相关博客。 博客地址

  • 同时结合最近的改动(之前 tpcds 可以正常执行,近期改动了相关的目录)

最终定位到报错原因是 yarn container 的目录过长。

解决方法:最终选择方法 2

1. 修改源码,更改目录相关逻辑

这个方法也是有些博客的解决方法。这里我并不推荐,从源码上来看,topcds 生成元数据的逻辑是

  • 根据参数划分并行度,任务启动后每个 container 都会通过分部署缓存拉取 dbgen 相关 jar 包
  • 每个并行度的 container 都会调用 dbgen 数据生成脚本生成数据。
  • 所有并行度生成数据之后。上传到 hdfs。(container 执行之后也会自动清理目录)

如果更改执行目录,需要考虑目录的创建清理逻辑,可能还需要 dbgen jar 包拷贝逻辑,为了避免有改动遗漏的地方,浪费时间,个人感觉非必要情况下,方法 1 了解原理即可,最终用方法 2 规避问题。
其中方法 1 可以参考参考链接(本人未验证过),修改源码之后注意进行多次测试。

2. 直接更改 Yarn container 的目录参数:yarn.nodemanager.log-dirs 为层次较浅的目录

因为使用该框架的本质目的是测试基准性能,而更改 Yarn 的 container 日志目录并不影响基准性能。所以直接更改目录参数是最便捷的方法。最终这个也是我采用的方法。改为 2 - 3 层是可以正常运行的。

参考链接:

TPCDS-Hive-testbench 运行报错 status-139

【TPCDS】记一个 Hive testbench 运行报错 statu 139 的问题


正文完
欢迎关注个人公众号, 内含各种工具及大厂内推码合集
post-qrcode
 0
HTML文本

本文链接:

nebofeng
版权声明:本站原创文章,由 nebofeng 于2022-12-08发表,共计1300字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)
验证码