tez的 Container killed on request. Exit code is 143问题

最新推荐文章于 2023-11-30 18:10:30 发布
原创 最新推荐文章于 2023-11-30 18:10:30 发布 · 1.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#数据仓库

在使用Tez进行数据导入时遇到错误，起初误以为是内存问题，但发现是在插入少量数据时出现问题。错误信息显示Container被异常杀死，退出代码为143。进一步检查发现原表的某个分区未创建，导致导入失败。创建缺失的分区后，数据成功导入。总结经验，确保目标表的分区存在是避免此类问题的关键。
部署运行你感兴趣的模型镜像

今天遇到了一个tez的错误记录一下:
在导入数据的时候出现了下面错误, 起初我以为是内存问题, 但一想,插入那么多数据都没问题,怎么插入几条数据就出现问题了呢?

Container killed on request. Exit code is 143
Container exited with a non-zero exit code 143
Failing this attempt. Failing the application

解决分析: 我查了查原表的数据和分区, 才发现原表的这个分区根本就没有创建, 怎么可以会导入成功呢? 这样我又去创建了一下分区, 并导入了一条数据,终于出现导入成功了,

总结: 原表的这个分区不存在

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型，相比 3.0 版本，它提升了图像质量、运行速度和硬件效率

Container killed on request. Exit code is 143
SunnyRivers
02-29 1300
大部分时候都是直接加大内存来解决，不要把太多精力放在这方面的调优。
hive on tez 执行报错 Container killed on request. Exit code is 137
yy的博客
01-07 1089
报错信息 ---------------------------------------------------------------------------------------------- VERTICES MODE STATUS TOTAL COMPLETED RUNNING PENDING FAILED KILLED -----------------------------------------------------------
spark sql运行出错（Container killed on request. Exit code is 143）
热门推荐
yijichangkong的专栏
05-06 5万+
错误描述：SQL三张表做join运行出错；用hive执行报错如下： Diagnostic Messages for this Task: Container [pid=27756,containerID=container_1460459369308_5864_01_000570] is running beyond physical memory limits. Current usag
解决运行MapReduce时遇到:Container killed on request. Exit code is 143
ZCYlee的博客
07-26 5736
背景描述：解决运行MapReduce时遇到:Container killed on request. Exit code is 143 问题分析：内存分配不足 需要对MapReduce和yarn的xml文件参数进行调整 在这里修改： [master@hadoop102 hadoop]$ vim mapred-site.xml 增加内容为： <property> <name>mapreduce.map.memory.mb</name> <valu
Hadoop Container killed on request. Exit code is 143Container exited with
hongxiao2016的博客
03-30 6405
Hadoop Container killed on request. Exit code is 143 Container exited with a non-zero exit code 143. 可能是hadoop内存不足，重新调整内存就可以了 vmware 修改主机内存 先关闭主机 编辑虚拟机设置 修改完成后确认退出重启 ...
执行错误：请求终止，容器被杀死。退出代码是编程
CodeLancerX的博客
09-09 190
总结起来，当遇到"Hive on Tez执行报错 Container killed on request. Exit code is 编程"的错误时，我们应该首先检查资源是否充足，然后调整作业的设置，例如内存和并行度。在使用Hive on Tez执行作业时，有时候可能会遇到类似于"Container killed on request. Exit code is 编程"的错误。如果问题仍然存在，建议您仔细检查作业的设置和代码，或者向相关社区和论坛寻求帮助。执行错误：请求终止，容器被杀死。
Hive On Tez报错汇总
TomAndersen的博客
06-04 2030
前言 Hive：2.3.0 Hadoop：2.7.7 JDK：1.8.0_221 Tez：0.9.1 报错一 报错内容： 在Hive下使用Tez引擎执行MR Job时报错：Container killed on request. Exit code is 143 问题分析： 从Container killed on request这几个关键字就可以猜测，Container在非正常结束时被kill，很有可能就是Container使用的内存超出Container限制导致的。 查看Hive运行日志： Hiv
hive on tez 错误记录
weixin_34206899的博客
06-19 2757
1、执行过程失败，报Container killed on request. Exit code is 143 如下图： 分析：造成这种原因是由于总内存不多，而容器在jvm中占比过高，修改tez-site.xml文件，添加如下配置： <property> <name>tez.container.max.java....
在hive上运行insert语句，报检查虚拟内存大小不够问题，tez
YellowXiuHui的博客
04-04 1163
1.由于Hive合成了Tez引擎，Tez加载需要预留大量的内存，所以才高速运行。有时会报这个错 Container killed on request. Exit code is 143 Container exited with a non-zero exit code 143 Failing this attempt. Failing the application. 2020-04-04T1...
Container killed on request. Exit code is 143_Permission denied: user=dr.who, a---Hadoop3.x启动报错记录001
添柴程序猿的专栏
02-24 669
Permission denied: user=dr.who, access=WRITE, inode="/":root:supergroup:drwxr-xr-x 这个错误。Permission denied: user=dr.who, access=WRITE, inode="/":root:supergroup:drwxr-xr-x 这个错误。这里的关键就是配置这个静态用户为自己的用户,这个配置好了,就可以删除了.在hdfs网页端删除某个文件,文件夹的时候,报错,说当前使用66.9MB。
【问题记录】hadoop3.1报错Container killed on request. Exit code is 143，因为内存导致
qq_65258287的博客
11-30 860
【代码】【问题记录】hadoop3.1报错Container killed on request. Exit code is 143，因为内存导致。
Hive SQL任务执行报错 (Container killed on request. Exit code is 143)
小陈陈陈陈.的博客
04-24 1353
Container killed on request. Exit code is 143，Container exited with a non-zero exit code 143
【MAPREDUCE】MapReduce : Container killed on request. Exit code is 143
Zsigner的博客
10-11 1371
错误具体详情： Container [pid=19750,containerID=container_e41_1570670743082_0094_01_000027] is running beyond physical memory limits. Current usage: 1.0 GB of 1 GB physical memory used; 10.1 GB of 2.1 GB vi...
运行MapReduce遇到:Container killed on request. Exit code is 143报错
weixin_43586713的博客
05-09 1399
最后执行失败,多半原因是因为内存分配不足导致的,对Mapreduce和yarn进行调整参数. 在yarn-site.xml文件中添加如下的内容: <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>22528</value> <discription>每个节点可用内存,单位MB</discription> </p.
hadoop container killed on request. exit is 143
m0_67401228的博客
08-29 725
https://www.suibibk.com/topic/634440889984352256
我可以只设置hive.tez.container.max.java.heap.fraction=0.8吗，这样比设置hive.tez.java.opts=6144;更保险，但我有个疑问，hive.tez.container.max.java.heap.fraction=0.8应该是默认值，当set tez.task.resource.memory.mb=10240;时堆内存不应该是8GB吗，为什么读取了HIVE_GC_OPTS="-Xms4096M -Xmx4096M"
最新发布
08-05
<think>我们首先需要理解用户的问题：在Hive on Tez引擎中，设置`hive.tez.container.max.java.heap.fraction=0.8`是否比直接配置`hive.tez.java.opts`更安全？以及为什么在设置`tez.task.resource.memory.mb=10240`（即10GB）时，堆内存没有达到预期的8GB（10GB的80%）而是受到`HIVE_GC_OPTS`中`-Xmx4096M`（4GB）的限制？ 根据引用[2]中的信息，我们可以知道： - `hive.tez.container.size`（即`tez.task.resource.memory.mb`）设置的是容器总内存（物理内存）。 - `hive.tez.java.opts`用于直接设置JVM堆内存（如`-Xmx`参数）。 - 同时，还有一个参数`tez.container.max.java.heap.fraction`（在Hive配置中可能是`hive.tez.container.max.java.heap.fraction`）用于控制容器内存中分配给JVM堆的最大比例。 用户的问题核心在于：当同时存在多个内存配置参数时，哪个参数会生效？以及为什么会出现堆内存被限制在4GB而不是8GB的情况？ ### 1. **参数优先级与生效规则** 在Tez中，JVM堆内存大小的确定遵循以下规则（按优先级从高到低）： 1. **显式设置`hive.tez.java.opts`中的`-Xmx`值**：如果在该参数中指定了`-Xmx`，则以此值为准。 2. **通过`hive.tez.container.max.java.heap.fraction`计算**：如果没有显式设置`-Xmx`，则JVM堆内存大小由公式计算得出： $$ \text{JVM堆内存} = \text{tez.task.resource.memory.mb} \times \text{hive.tez.container.max.java.heap.fraction} $$ 3. **默认值**：如果以上均未设置，则使用JVM默认的堆内存比例（通常为容器内存的1/4左右）。 ### 2. **用户配置冲突分析** 用户配置： - `HIVE_GC_OPTS`中设置了`-Xmx4096M`（即4GB），这相当于在JVM启动参数中固定了最大堆内存为4GB。 - `tez.task.resource.memory.mb`（或`hive.tez.container.size`）设置为10240MB（10GB）。 - 设置了`hive.tez.container.max.java.heap.fraction=0.8`，期望堆内存为10GB×0.8=8GB。 **为什么堆内存没有达到8GB？** 因为`HIVE_GC_OPTS`中的`-Xmx4096M`是显式的JVM参数，它的优先级最高。无论其他参数如何设置，JVM都会将堆内存上限锁定在4GB。因此，即使通过比例计算应该得到8GB，实际堆内存仍然被限制在4GB。 ### 3. **安全性对比** - **直接设置`hive.tez.java.opts`（如`-Xmx8192m`）**： - **优点**：精确控制堆内存大小。 - **缺点**：需要手动计算并确保与容器内存（`tez.task.resource.memory.mb`）匹配。如果容器内存不足，可能导致YARN杀死容器（例如堆外内存溢出）。 - **设置`hive.tez.container.max.java.heap.fraction`**： - **优点**：自动按比例分配堆内存，避免手动计算错误。当调整容器大小时，堆内存自动按比例调整，更安全灵活。 - **缺点**：需要确保容器内存设置合理，且比例值（如0.8）适合任务需求。 引用[2]中明确建议： > hive.tez.java.opts=-Xmx1700m # Java内存设置，该值不建议直接设置，而是调整tez.container.max.java.heap.fraction参数（默认0.8）[^2]。 因此，**使用`hive.tez.container.max.java.heap.fraction`更安全**，因为它： 1. 避免人为计算错误。 2. 自动适应容器内存变化。 3. 预留堆外内存空间（如JVM自身、本地库、线程栈等），防止容器因总内存超限被YARN杀死。 ### 4. **正确配置示例** 若期望堆内存为容器内存的80%，且容器内存为10GB，应： 1. **移除`HIVE_GC_OPTS`中的`-Xmx`参数**（或确保其不覆盖Tez设置）。 2. 设置`hive.tez.container.size=10240`（即10GB）。 3. 设置`hive.tez.container.max.java.heap.fraction=0.8`。 4. 不设置`hive.tez.java.opts`中的`-Xmx`（或仅设置GC参数）。 此时JVM堆内存将自动计算为： $$ 10240 \times 0.8 = 8192 \text{MB} $$ ### 5. **参数冲突解决建议** - **检查配置覆盖关系**：Hive的配置可能被多个文件（如`hive-site.xml`、环境变量）覆盖，需确保`-Xmx`不在最终生效的JVM参数中。 - **日志验证**：在Tez任务日志中搜索`-Xmx`，确认实际生效值。 - **统一管理原则**：推荐仅通过`hive.tez.container.max.java.heap.fraction`控制堆比例，避免混用直接设置方式。 ### 总结 1. **优先级问题**：`HIVE_GC_OPTS`中的`-Xmx4096M`优先级最高，导致堆内存被锁定为4GB，无视其他比例设置。 2. **安全性结论**：使用`hive.tez.container.max.java.heap.fraction`比直接设置`hive.tez.java.opts`更安全，可自动适配容器内存变化并预留堆外空间。 3. **配置建议**：移除显式`-Xmx`设置，通过容器内存和堆比例参数控制堆大小。 §§相关问题§§ 1. 如何查看Tez任务实际生效的JVM堆内存参数？ 2. 如何预留足够堆外内存以避免YARN杀死容器？ 3. Hive on Tez中常见的OOM（堆内存/堆外内存）有哪些解决方案？ 4. 为什么Tez需要比MapReduce更多的内存管理配置？</think>### 核心问题解析 根据您的配置和引用内容，关键矛盾在于 **Tez容器的堆内存分配机制** 与 **JVM参数`-Xmx`的强制限制** 之间的优先级冲突。以下是逐层分析： --- ### 1. 堆内存控制机制对比 #### (1) `hive.tez.container.max.java.heap.fraction`（比例控制） ```properties # 计算逻辑 实际堆内存 = tez.task.resource.memory.mb × hive.tez.container.max.java.heap.fraction ``` - **优势**：动态安全（引用[2]明确推荐[^2]） - 自动适配容器内存变化 - 预留堆外内存空间（JVM自身、本地库、线程栈等） - 避免容器因总内存超限被YARN杀死 - **示例**： 当 `tez.task.resource.memory.mb=10240` (10GB) 且 `fraction=0.8` 时 预期堆内存 = $10240 \times 0.8 = 8192\text{MB}$ (8GB) #### (2) 直接配置 `hive.tez.java.opts`（显式指定） ```properties hive.tez.java.opts = "-Xmx8192m" # 强制固定堆内存 ``` - **风险**（引用[2]警告[^2]）： - 易导致堆外内存溢出（容器总内存 - 堆内存 < 预留需求） - 需手动计算预留空间（通常需预留20%+） - 容器内存调整时需同步修改 > ✅ **结论**：`hive.tez.container.max.java.heap.fraction` **更安全**，是Tez官方推荐做法[^2][^3] --- ### 2. 堆内存未达8GB的根本原因 #### 配置冲突优先级 ```mermaid graph LR A[tez.task.resource.memory.mb=10240] --> B[比例计算期望堆=8GB] C[HIVE_GC_OPTS中-Xmx4096M] --> D[实际生效堆=4GB] D -->|优先级更高| B ``` - **JVM参数`-Xmx`具有最高优先级** 无论Tez如何计算，JVM启动时以`-Xmx`值为准 - **证据链**： 1. `HIVE_GC_OPTS`包含`-Xmx4096M`（固定堆上限4GB） 2. Tez的`hive.tez.java.opts`未显式覆盖（引用[1]中值为`-Xmx1048m`[^1]） 3. 比例参数仅当未设`-Xmx`时生效 > ⚠️ 因此：**`-Xmx4096M`强制覆盖了比例计算值**，导致堆内存锁定在4GB --- ### 3. 安全配置方案 #### 正确配置步骤（基于引用[2]推荐[^2]） ```properties # 步骤1：移除HIVE_GC_OPTS中的-Xmx限制 HIVE_GC_OPTS = ... # 删除-Xmx4096M和-Xms4096M # 步骤2：设置容器总内存（物理内存） set hive.tez.container.size=10240; # 10GB容器 # 步骤3：启用动态比例控制 set hive.tez.container.max.java.heap.fraction=0.8; # 步骤4：预留堆外空间（关键！） set hive.tez.java.opts="-XX:MaxDirectMemorySize=1g"; # 显式指定堆外内存，避免溢出 ``` #### 参数关系验证表 | 配置项 | 值 | 作用 | 是否必需 | |--------|----|------|----------| | `tez.task.resource.memory.mb` | 10240 | 容器总内存 | ✅ | | `hive.tez.container.max.java.heap.fraction` | 0.8 | 堆内存比例 | ✅ | | `-Xmx` | **不设置** | 由比例自动计算 | ❌ | | `-XX:MaxDirectMemorySize` | 1g | 堆外内存保护 | ✅ | --- ### 4. 为何比例控制更安全？数学解释 定义容器安全边界： $$ \begin{align*} \text{堆外内存需求} & \approx \text{JVM元数据} + \text{线程栈} + \text{Direct Buffer} \\ & \geq 0.15 \times \text{容器总内存} \quad \text{(经验值)} \end{align*} $$ 比例控制自动满足： $$ \text{堆内存} + \text{堆外内存} \leq \text{容器总内存} $$ 当 `fraction=0.8` 时： $$ \text{堆外缓冲} = 1 - 0.8 = 20\% $$ 完美覆盖15%的最低需求[^2]。 --- ### 总结 1. **`hive.tez.container.max.java.heap.fraction`比直接设`-Xmx`更安全** 自动保证堆外内存空间，避免容器被YARN杀死 2. **堆内存未达8GB是因`-Xmx4096M`强制覆盖** JVM参数优先级高于Tez比例计算 3. **解决方案**： - 移除`HIVE_GC_OPTS`中的`-Xmx/Xms` - 启用`hive.tez.container.max.java.heap.fraction=0.8` - 显式设置`-XX:MaxDirectMemorySize`保护堆外内存 > 📌 最终效果：当`tez.task.resource.memory.mb=10240`时，堆内存将自动升到$10240 \times 0.8 = 8192\text{MB}$，且安全预留$2048\text{MB}$堆外空间。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值