事件： datax on yarn 3点出现任务失败，错误信息：[Error] DataX receive unexpected signal 15, starts to suicide。jdk还打印了stack信息。 问题分析： signal15为外部kill，jvm打印thread dump也是由于kill产生，尤其是kill -3会thread dump。 是机器内存不足被OS kill? 到/var/log/messages寻找，无相关日志，机器内存监控显示内存充足。 yarn资源抢占，被yarn rm kill了？ 集群使用fair + drf调度策略，并开启了资源抢占。不同的队列之间资源会相互竞争和抢占。定位问题，寻找rm的日志，找到对应container被kill的日志。 添加yarn抢占容器数量监控 Hadoop_ResourceManager_AggregateContainersPreempted{name=”QueueMetrics”,q0=”root”, user=””,instance=”x.x.x.x:7011″} 解决方式： 1、队列划分更精细，资源划分按业务，调整配比 2、关闭资源抢占 原理： FIFO Scheduler、Capacity Scheduler、Fair Scheduler 什么时候发生抢占？ Ø 最小资源抢占, 当前queue的资源无法保障时，而又有apps运行，需要向外抢占。Ø 公平调度抢占, 当前queue的资源为达到max，而又有apps运行，需要向外抢占。 具体详见yarn源码实现。 参考： https://cloud.tencent.com/developer/article/1195056 YARN资源调度策略
The Youth’s Companion, Feb.7 1889, p.73(Vol 62) JUST THE BOY WANTED, II IN THE LAW, by Judge Oliver Wendell Holmes (from Howe, Mark DeWolfe. Research materials relating to life of Oliver Wendell Holmes.) A boy who wants to succeed in the law will probably do so. An encouraging thought, as far as it goes. But […]
场景：join时的过滤条件下推 需求：快速查看sql结果的schema，用于平台可视化配置 判断标识：explain sql语句看table scan时的stage的predicate是否有内容 开关：hive2的cbo，hive1的ppd 用途：提升sql性能&节约开销、查询复杂语句的结果集schema 先说结论：hiveserver2的谓词下推作用十分有限。 测试环境：hive3.1.2 结果 当把1=2，改成某字段=2，发生了谓词下推 场景，快速获取sql的结果集schema。 1=2或limit 1不能解决快速查sql schema的问题，对于涉及到join的sql，都无法快速返回。即使使用了谓词下推或将limit 1放入子查询，依然是要去数据集获取数据过滤，再执行join，依然不快。 结果 看具体执行截图 dbeaver client提交耗时71秒 看看具体耗时在哪 Mr: 69秒 关于hiveserver2谓词下推的资料： https://cloud.tencent.com/developer/article/1616687
