download：Android面试超级攻略，全面攻破技术疑难及面试痛点
0.前言
前阵子在生产上碰到了一个诡异景象：全量作业无奈失常进行，日志中充斥着java.util.concurrent.TimeoutException: Heartbeat of TaskManager with id container xxxx(HOSTNAME:PORT) timed out的报错。
场景为Oracle全量抽取至Hive，数据会流过Kafka，数据量为T级别，依据工夫字段每天做一个分区。报错的Job负责抽取Kafka的数据并写至Hive，应用的是TableAPI。
1.排查思路
这个问题报到我这边的时候，有同学曾经排查过一轮了。依据网上搜寻，会告知你可能是yarn的压力过大、网络短暂不稳固等，能够调大heartbeat.timeout来缓解这个问题，经调整改问题并未解决。
另外一个说法会告知你是GC频繁的起因。倡议调整内存，调整后，确实有肯定的成果（使出问题的工夫变慢）。那很显然和代码有关系了。
因为之前一个版本同步数据都没有出问题，因而开始寻找最近代码的改变，找了几圈下来并没有找到可疑的代码。登时感觉有点头皮发麻。于是让现场的同学切换到上个版本持续做全量，景象依旧会产生。
这时我就有点狐疑生产环境的个性了——比方数据个性，但现场的同学告知我数据并没有什么非凡之处。于是我要了一份现场的HeapDump，丢到了剖析软件上进行查看，发现org.apache.flink.streaming.api.functions.sink.filesystem.Bucket的对象特地多。
搞代码网（gaodaima.com）提供的所有资源部分来自互联网，如果有侵犯您的版权或其他权益，请说明详细缘由并提供版权或权益证明然后发送到邮箱[email protected]，我们会在看到邮件的第一时间内为您处理，或直接联系QQ：872152909。本网站采用BY-NC-SA协议进行授权
转载请注明原文链接：Android面试超级攻略全面攻破技术疑难及面试痛点吾爱
转载请注明原文链接：Android面试超级攻略全面攻破技术疑难及面试痛点吾爱
