AS3 点点【 二 】 stage-root-this

[img]http://lh6.ggpht.com/_YE8sr7aRsWc/SadlR4fzj7I/AAAAAAAAA6g/GYfC4pLZ_xE/stage-root-this.gif?imgmax=800[/img]

stage-root-this
先看Flash帮助文档里的图示,最上边的舞台就是stage了,root属于第2层,也就是说root是stage的子类,这2者的关系可以使用下边代码测试:

trace(stage);//[object Stage]
trace(root);//[object MainTimeline]
trace(root.parent);//[object Stage]
trace(root.parent==stage);//true

另外继承方面:Stage -> DisplayObjectContainer -> InteractiveObject -> DisplayObject -> EventDispatcher -> Object。
而root则是继承自DisplayObject。至于this,和其他OOP语言一样,是指向当前引用的对象,例如在主时间轴上的this,就是root。
hive> select phone_no,round(avg(should_pay-favour_fee),2) as average > from mmconsume_billevents > group by phone_no,year(year_month) > having year(year_month)=2022 > order by average desc > limit 20; Query ID = root_20250312155033_cc0e1609-f3fd-4957-aa79-acb2b53570b0 Total jobs = 2 Launching Job 1 out of 2 Number of reduce tasks not specified. Estimated from input data size: 1 In order to change the average load for a reducer (in bytes): set hive.exec.reducers.bytes.per.reducer=<number> In order to limit the maximum number of reducers: set hive.exec.reducers.max=<number> In order to set a constant number of reducers: set mapreduce.job.reduces=<number> Starting Job = job_1741761349018_0009, Tracking URL = http://master:8088/proxy/application_1741761349018_0009/ Kill Command = /opt/module/hadoop/bin/mapred job -kill job_1741761349018_0009 Hadoop job information for Stage-1: number of mappers: 1; number of reducers: 1 2025-03-12 15:51:23,088 Stage-1 map = 0%, reduce = 0% 2025-03-12 15:52:05,416 Stage-1 map = 100%, reduce = 100% Ended Job = job_1741761349018_0009 with errors Error during job, obtaining debugging information... Examining task ID: task_1741761349018_0009_m_000000 (and more) from job job_1741761349018_0009 Task with the most failures(4): ----- Task ID: task_1741761349018_0009_m_000000 URL: http://master:8088/taskdetails.jsp?jobid=job_1741761349018_0009&tipid=task_1741761349018_0009_m_000000 ----- Diagnostic Messages for this Task: [2025-03-12 15:52:04.306]Container [pid=24669,containerID=container_1741761349018_0009_01_000005] is running 268872192B beyond the &#39;VIRTUAL&#39; memory limit. Current usage: 107.2 MB of 1 GB physical memory used; 2.4 GB of 2.1 GB virtual memory used. Killing container. Dump of the process-tree for container_1741761349018_0009_01_000005 : |- PID PPID PGRPID SESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES) RSSMEM_USAGE(PAGES) FULL_CMD_LINE |- 25111 24669 24669 24669 (java) 473 26 2513932288 27155 /opt/module/java/bin/java -Djava.net.preferIPv4Stack=true -Dhadoop.metrics.log.level=WARN -Xmx820m -Djava.io.tmpdir=/opt/module/hadoop/data/nm-local-dir/usercache/root/appcache/application_1741761349018_0009/container_1741761349018_0009_01_000005/tmp -Dlog4j.configuration=container-log4j.properties -Dyarn.app.container.log.dir=/opt/module/hadoop/logs/userlogs/application_1741761349018_0009/container_1741761349018_0009_01_000005 -Dyarn.app.container.log.filesize=0 -Dhadoop.root.logger=INFO,CLA -Dhadoop.root.logfile=syslog org.apache.hadoop.mapred.YarnChild 192.168.184.140 44940 attempt_1741761349018_0009_m_000000_3 5 |- 24669 24668 24669 24669 (bash) 4 9 9797632 287 /bin/bash -c /opt/module/java/bin/java -Djava.net.preferIPv4Stack=true -Dhadoop.metrics.log.level=WARN -Xmx820m -Djava.io.tmpdir=/opt/module/hadoop/data/nm-local-dir/usercache/root/appcache/application_1741761349018_0009/container_1741761349018_0009_01_000005/tmp -Dlog4j.configuration=container-log4j.properties -Dyarn.app.container.log.dir=/opt/module/hadoop/logs/userlogs/application_1741761349018_0009/container_1741761349018_0009_01_000005 -Dyarn.app.container.log.filesize=0 -Dhadoop.root.logger=INFO,CLA -Dhadoop.root.logfile=syslog org.apache.hadoop.mapred.YarnChild 192.168.184.140 44940 attempt_1741761349018_0009_m_000000_3 5 1>/opt/module/hadoop/logs/userlogs/application_1741761349018_0009/container_1741761349018_0009_01_000005/stdout 2>/opt/module/hadoop/logs/userlogs/application_1741761349018_0009/container_1741761349018_0009_01_000005/stderr [2025-03-12 15:52:04.442]Container killed on request. Exit code is 143 [2025-03-12 15:52:04.462]Container exited with a non-zero exit code 143. FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask MapReduce Jobs Launched: Stage-Stage-1: Map: 1 Reduce: 1 HDFS Read: 0 HDFS Write: 0 FAIL Total MapReduce CPU Time Spent: 0 msec
03-13
<think>嗯,用户给了一个Hive查询的执行日志,里面报错了,需要我帮忙分析解决。首先,我得仔细看看日志内容,找出错误的原因。 首先,用户执行的查询是计算每个电话号码在2022年的平均消费,按平均值降序取前20。看起来逻辑没问题,但执行时出错了。日志里提到任务失败,最关键的报错信息是内存超限。具体来说,Container因为超出虚拟内存限制被终止了,当前使用了2.4GB的虚拟内存,而限制是2.1GB。这说明内存不足,可能是Hadoop的Yarn配置问题。 接下来,我需要回忆Hadoop和Yarn的内存管理机制。Yarn中每个容器的内存分配包括物理内存和虚拟内存,虚拟内存通常是物理内存的倍数,默认可能是2.1倍。如果任务使用的虚拟内存超过这个限制,就会被杀掉。这里的物理内存是1GB,虚拟内存限制是2.1GB,而任务用了2.4GB,显然超过了。 那解决办法通常有几种:调整Yarn的内存配置,增加每个容器的物理内存,或者调高虚拟内存的比率。另外,Hive这边可能也需要优化查询,减少数据量或者调整并行度。 用户可能需要检查几个配置参数,比如mapreduce.map.memory.mb和mapreduce.reduce.memory.mb,这些控制每个任务的物理内存。还有yarn.nodemanager.vmem-pmem-ratio,这个控制虚拟内存的比率,默认是2.1,可以适当调大,比如4,这样虚拟内存限制就变成物理内存的4倍,可能就不会超了。 另外,用户还可以尝试优化查询,比如检查year_month字段的过滤条件是否有效,或者数据是否倾斜,导致某个任务处理的数据量过大。数据倾斜的话,可能需要预处理数据,或者调整分片策略。 也有可能用户的环境里Hive或Hadoop版本有问题,或者资源不足,需要增加集群资源。但作为临时的解决办法,调整内存配置是比较直接的。 总结下来,用户需要修改Yarn的内存配置,增加容器内存或虚拟内存比率,同时检查查询是否有优化空间。如果用户是测试环境,可能直接调参就行;生产环境的话可能需要更谨慎,避免影响其他任务。</think>这个Hive查询执行失败的主要原因是**容器内存超限**。错误信息显示任务使用的虚拟内存超过Yarn配置的阈值,导致容器被强制终止。以下是逐步分析和解决方案: --- ### **步骤一:理解错误原因** 错误日志关键信息: ```plaintext Container is running 268872192B beyond the &#39;VIRTUAL&#39; memory limit. Current usage: 107.2 MB of 1 GB physical memory used; 2.4 GB of 2.1 GB virtual memory used. ``` - **物理内存**:任务实际使用1GB中的107.2MB(未超限)。 - **虚拟内存**:任务使用2.4GB,但Yarn限制为2.1GB(物理内存的2.1倍),触发强制终止。 --- ### **步骤:Hadoop/Yarn内存机制** 1. **虚拟内存限制公式**: $$虚拟内存阈值 = mapreduce.\{map/reduce\}.memory.mb \times yarn.nodemanager.vmem-pmem-ratio$$ - 默认比率`yarn.nodemanager.vmem-pmem-ratio=2.1` - 本例中:`1GB * 2.1 = 2.1GB`,但任务使用了2.4GB,超出限制。 --- ### **步骤三:解决方案** #### **方案1:调高虚拟内存比率** 在`yarn-site.xml`中调整参数: ```xml <property> <name>yarn.nodemanager.vmem-pmem-ratio</name> <value>4</value> <!-- 调整为物理内存的4倍 --> </property> ``` #### **方案2:增加容器物理内存** 在`mapred-site.xml`中增加容器内存分配: ```xml <property> <name>mapreduce.map.memory.mb</name> <value>2048</value> <!-- 调高Map任务内存 --> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>2048</value> <!-- 调高Reduce任务内存 --> </property> ``` #### **方案3:优化Hive查询** - **检查数据倾斜**:`phone_no`或`year_month`字段可能导致某些组数据量过大。 - **提前过滤数据**:在子查询中先过滤2022年数据,减少处理量: ```sql SELECT phone_no, ROUND(AVG(should_pay - favour_fee), 2) AS average FROM ( SELECT * FROM mmconsume_billevents WHERE YEAR(year_month) = 2022 ) filtered GROUP BY phone_no, YEAR(year_month) ORDER BY average DESC LIMIT 20; ``` --- ### **步骤四:应用配置后重试** 1. 修改配置后**重启Yarn和Hive服务**。 2. 重新执行查询,观察日志是否仍有内存错误。 --- ### **补充建议** - **监控资源使用**:通过Yarn Web UI(`http://master:8088`)实时监控任务资源消耗。 - **调整并行度**:通过`set mapreduce.job.reduces=2;`指定Reducer数量,避免默认单Reducer负载过高。 通过上述调整,应能解决内存超限问题。如果问题持续,需检查集群硬件资源是否充足或排查数据倾斜问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值