hi，all
遇到这种场景，flink on yarn，并行度3000的场景下，作业包含了多个agg操作，作业recover from checkpoint
或者savepoint必现无法恢复的情况，作业反复重启
jm报错org.apache.flink.runtime.entrypoint.ClusterEntrypoint[] - RECEIVED S
IGNAL 15: SIGTERM. Shutting down as requested.
请问有什么好的排查思路吗
，
FlinkLogicalCalcRemoveRule.INSTANCE
2. projection push into tablesource 可查看：PushProjectIntoTableSourceScanRule
Best，
Hailong
在 2020-12-15 20:57:32，"SmileSmile" 写道：
>hi，社区的各位，是否有了解flink sql的列裁剪的实现原理？
>
>通过calcite的rbo可以实现sql优化，calcite的coreRules好像没有实现列裁剪。看一些文章有提到flink有实现projection
>pushdow
hi，社区的各位，是否有了解flink sql的列裁剪的实现原理？
通过calcite的rbo可以实现sql优化，calcite的coreRules好像没有实现列裁剪。看一些文章有提到flink有实现projection
pushdown。请问下这部分源码对应哪里
Best！
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
hicheckpoint??
Best
| |
a511955993
|
|
??a511955...@163.com
|
??
??2020??09??04?? 14:11??op ??
----
??:
不影响正常使用
失败的原因是slot 5分钟申请超时了，你给的日志里面2020-07-23 13:55:45,519到2020-07-23
13:58:18,037是空白的，没有进行省略吧？
这段时间按理应该是task开始deploy了。在日志里看到了JM->RM的心跳超时，同一个Pod里面的同一个进程通信也超时了
所以怀疑JM一直在FullGC，这个需要你确认一下
Best,
Yang
SmileSmile 于2020年7月23日周四 下午2:43写道：
> Hi Yang Wang
>
> 先分享下我这边的环境版本
>
>
> kub
54]这两个JIRA并不会影响TM向RM注册时候的使用的地址
如果你想找到根本原因，那可能需要你这边提供JM/TM的完整log，这样方便分析
Best,
Yang
SmileSmile 于2020年7月23日周四 上午11:30写道：
>
> Hi Yang Wang
>
> 刚刚在测试环境测试了一下，taskManager没有办法nslookup出来，JM可以nslookup，这两者的差别在于是否有service。
>
> 解决方案：我这边给集群加上了taskmanager-query-state-service.yaml（按照官网上是可选服务）
Wang wrote:
我的意思就是你在Flink任务运行的过程中，然后下面的命令在集群里面起一个busybox的pod，
在里面执行 nslookup {ip_address}，看看是否能够正常解析到。如果不能应该就是coredns的
问题了
kubectl run -i -t busybox --image=busybox --restart=Never
你需要确认下集群的coredns pod是否正常，一般是部署在kube-system这个namespace下的
Best,
Yang
SmileSmile 于2020年7月22日周三 下午7:57写道：
>
&
的
如果你的日志里面一直在刷No hostname could be resolved for the IP address，应该是集群的coredns
有问题，由ip地址反查hostname查不到。你可以起一个busybox验证一下是不是这个ip就解析不了，有
可能是coredns有问题
Flink里面用的是InetAddress#getHostFromNameService来跟进IP地址获取FQDN的
Best,
Yang
SmileSmile 于2020年7月10日周五 下午1:10写道：
> hi Yang
>
> 在1.10版本，running的作业
发现
> Best,
> Congxian
>
>
> SmileSmile 于2020年7月21日周二 下午3:19写道：
>
> > Hi，Congxian
> >
> > 因为是测试环境，没有配置HA，目前看到的信息，就是JM刷出来大量的no hostname could be
> > resolved，jm失联，作业提交失败。
> > 将jm内存配置为10g也是一样的情况（jobmanager.memory.pprocesa.size：10240m）。
> >
> >
我这边也验证了一下，在你所说的地方确实是ip:port，但是提交任务都是正常的
如果你的日志里面一直在刷No hostname could be resolved for the IP address，应该是集群的coredns
有问题，由ip地址反查hostname查不到。你可以起一个busybox验证一下是不是这个ip就解析不了，有
可能是coredns有问题
Flink里面用的是InetAddress#getHostFromNameService来跟进IP地址获取FQDN的
Best,
Yang
SmileSmile 于2020年7月10日周五 下午1:10写道
Qiu wrote:
Hi
如果没有异常，GC 情况也正常的话，或许可以看一下 pod 的相关日志，如果开启了 HA 也可以看一下 zk 的日志。之前遇到过一次在 Yarn
环境中类似的现象是由于其他原因导致的，通过看 NM 日志以及 zk 日志发现的原因。
Best,
Congxian
SmileSmile 于2020年7月15日周三 下午5:20写道：
> Hi Roc
>
> 该现象在1.10.1版本没有，在1.11版本才出现。请问这个该如何查比较合适
>
>
>
> | |
> a511955993
> |
Hi Roc
该现象在1.10.1版本没有，在1.11版本才出现。请问这个该如何查比较合适
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
On 07/15/2020 17:16, Roc Marshal wrote:
Hi，SmileSmile.
个人之前有遇到过 类似 的host解析问题，可以从k8s的pod节点网络映射角度排查一下。
希望这对你有帮助。
祝好。
Roc Marshal
在 2020-07-15 17:04:18，"SmileSmile"
Hi
使用版本Flink 1.11，部署方式 kubernetes session。 TM个数30个，每个TM 4个slot。 job
并行度120.提交作业的时候出现大量的No hostname could be resolved for the IP address，JM time
out，作业提交失败。web ui也会卡主无响应。
用wordCount，并行度只有1提交也会刷，no hostname的日志会刷个几条，然后正常提交，如果并行度一上去，就会超时。
部分日志如下：
2020-07-15 16:58:46,460 WARN
个是哪里的？正常TM列表akka地址
都是ip地址的
Best,
Yang
SmileSmile 于2020年7月10日周五 上午10:42写道：
> hi yang wang
>
> 1.11版本的on kubernetes在hostname上有做什么变化吗？
>
> 作业运行的时候 flink ui上 tm变成ip：端口
> ，在1.10版本，ui上是 podname：端口。
>
> 作业启动的时候，jm日志一直在刷
>
> No hostname could be resolved for the IP
ons
[3]
https://github.com/apache/flink-docker/blob/master/1.11/scala_2.11-debian/docker-entrypoint.sh
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月08日 16:38，SmileSmile 写道：
hi yun tang！
没有对 /opt/flink/config 目录下的文件做写操作。 只是按照官网上的配置文件进行部署，镜像用的也是社区的镜像。
best！
| |
a511955993
configmap里面的内容，这样挂载时候就会自动更新了。
祝好
唐云
From: SmileSmile
Sent: Wednesday, July 8, 2020 13:03
To: Flink user-zh mailing list
Subject: flink 1.11 on kubernetes 构建失败
hi
按照文档[1]的方法部署session cluster on kubernetes，集群构建的时候出现了如下报错
Starting Task Manager
sed: couldn't open
hi
按照文档[1]的方法部署session cluster on kubernetes，集群构建的时候出现了如下报错
Starting Task Manager
sed: couldn't open temporary file /opt/flink/conf/sedVdyy6Q: Read-only file
system
sed: couldn't open temporary file /opt/flink/conf/sedcj5VKQ: Read-only file
system
/docker-entrypoint.sh: 72:
groupId: org.apache.flink
artifactId: flink-clients_${scala.binary.version}
Best,
Yangze Guo
On Wed, Jul 8, 2020 at 11:27 AM SmileSmile wrote:
>
>
> hi
>
> 作业的依赖从1.10.1升级到1.11.0，在idea运行的时候报错
>
> Exception in thread "main" java.lang.IllegalStateException: No
>
hi
作业的依赖从1.10.1升级到1.11.0，在idea运行的时候报错
Exception in thread "main" java.lang.IllegalStateException: No ExecutorFactory
found to execute the application.
at
org.apache.flink.core.execution.DefaultExecutorServiceLoader.getExecutorFactory(DefaultExecutorServiceLoader.java:84)
at
-fill
make
其次最好指定dump文件的输出地址，例如在 MALLOC_CONF中加上前缀的配置 prof_prefix:/tmp/jeprof.out
，以确保文件位置可写。
最后，由于你是在容器中跑，在容器退出前要保证相关文件能上传或者退出时候hang住一段时间，否则相关dump的文件无法看到了
祝好
唐云
From: SmileSmile
Sent: Monday, July 6, 2020 14:15
To: Yun Tang
Cc: user-zh@flink.apache.org
Subject
hi，社区的各位，是否有配置过jemalloc？
目前在docker容器中放入编译过后的jemalloc，在flink的配置文件加入如下配置
containerized.taskmanager.env.LD_PRELOAD: /opt/jemalloc/lib/libjemalloc.so
containerized.taskmanager.env.MALLOC_CONF:
prof:true,lg_prof_interval:25,lg_prof_sample:17,prof_prefix:/opt/state/jeprof.out
结果生成不到对应的heap文件，
se%3A-Heap-Profiling
[2] https://www.evanjones.ca/java-native-leak-bug.html
祝好
唐云
________
From: SmileSmile
Sent: Friday, July 3, 2020 15:22
To: Yun Tang
Cc: user-zh@flink.apache.org
Subject: 回复：rocksdb的block cache usage应该如何使用
Hi
作业只配置了重启策略，作业如果fail了，只会重启，没有恢复历史数据。
【
：
Hi
如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。
祝好
唐云
From: SmileSmile
Sent: Friday, July
usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory /
slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os
kill，使用的是从savepoint恢复数据么？
祝好
唐云
From: SmileSmile
Sent: Friday, July 3, 2020 14:20
To: Yun Tang
Cc: Flink user-zh mailing list
cache均是一个，这样你可以根据taskmanager和subtask_index
作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block
cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。
祝好
唐云
From: SmileSmile
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list
Subject: rocksdb的block cache usage应该如何使用
释放。
有一个疑问，如果没有开启ck，作业恢复后是重新开始的，重启前的旧数据在rocksdb中是在如何清理的呢？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 14:02，Congxian Qiu 写道：
理论上作业重启后，会释放内存，这里的问题从描述看，重启后有内存没有释放。能否在重启后 dump 一下内存看看呢？
或者你这个问题能够完全重现吗？可否告知一下如何复现这个问题呢
Best,
Congxian
SmileSmile 于2020年7月3日周五 下午12:23写道
这种现象只会出现在on rocksdb中。
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 11:21，SmileSmile 写道：
Hi
我的作业是运行在1.10.1, 使用的是event time ，没有开启checkPoint。每当作业重启一次，container memory
usage会上涨2G，每重启一次就会上涨一些内存直到被OS kill。
历史数据的清理是在新event time到达之后调用 WindowOperator#onEventTime()
的
Hi
我的作业是运行在1.10.1, 使用的是event time ，没有开启checkPoint。每当作业重启一次，container memory
usage会上涨2G，每重启一次就会上涨一些内存直到被OS kill。
历史数据的清理是在新event time到达之后调用 WindowOperator#onEventTime()
的clearAllState实现清理，如果作业重启，又没有开启checkpoint，尚未被处理的历史数据是否一直残留在内存中无法清理？
是否有哪位大佬可以帮忙解惑？
| |
a511955993
|
|
通过 state.backend.rocksdb.metrics.block-cache-usage: true开启
rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。
我们的作业一个TM的内存设置如下：
taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4
??OOMmetaspaceOOM??
----
??:""https://issues.apache.org/jira/browse/FLINK-11205
SmileSmile
：taskmanager.memory.off-heap: true.
目前来看，OOM被 kill 掉的问题没有在出现了。希望能帮到你。
Best,
LakeShen
SmileSmile 于2020年6月30日周二 下午11:19写道：
>
> 补充一下，内核版本为 3.10.x，是否会是堆外内存cache没被回收而导致的内存超用？
>
>
> | |
> a511955993
> |
> |
> 邮箱：a511955...@163.com
> |
>
> 签名由 网易邮箱大师 定制
>
> 在2
补充一下，内核版本为 3.10.x，是否会是堆外内存cache没被回收而导致的内存超用？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年06月30日 23:00，GuoSmileSmil 写道：
hi all，
我使用的Flink版本为1.10.1，使用的backend是rocksdb，没有开启checkpoint，运行在kubernetes平台上，模式是standalone。
32 matches
Mail list logo
