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

共计 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 的问题