flink on yarn 作业挂掉反复重启
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. 请问有什么好的排查思路吗
回复：Flink sql 列裁剪原理请教
hi，hailongwang project_remove可以消掉两个链接在一起的projection，如果只投影一个字段，可是经过好几层sql嵌套，底层投影了大量的字段。如何做到更好的列裁剪，这块flink的相关实现是否有？ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 在2020年12月15日 22:33，hailongwang 写道： Hi, 1. projection prune 可查看：CoreRules.PROJECT_REMOVE， 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 >pushdown。请问下这部分源码对应哪里 > >Best！ > > >| | >a511955993 >| >| >邮箱：a511955...@163.com >| > >签名由 网易邮箱大师 定制
Flink sql 列裁剪原理请教
hi，社区的各位，是否有了解flink sql的列裁剪的实现原理？ 通过calcite的rbo可以实现sql优化，calcite的coreRules好像没有实现列裁剪。看一些文章有提到flink有实现projection pushdown。请问下这部分源码对应哪里 Best！ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
??????FlinkKafkaConsumer????
hicheckpoint?? Best | | a511955993 | | ??a511955...@163.com | ?? ??2020??09??04?? 14:11??op ?? ---- ??: "user-zh"
Re: Flink 1.11 submit job timed out
Hi，Yang Wang 因为日志太长了，删了一些重复的内容。 一开始怀疑过jm gc的问题，将jm的内存调整为10g也是一样的情况。 Best | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 On 07/27/2020 11:36, Yang Wang wrote: 看你这个任务，失败的根本原因并不是“No hostname could be resolved ”，这个WARNING的原因可以单独讨论（如果在1.10里面不存在的话）。 你可以本地起一个Standalone的集群，也会有这样的WARNING，并不影响正常使用 失败的原因是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 > > 先分享下我这边的环境版本 > > > kubernetes：1.17.4. CNI： weave > > > 1 2 3 是我的一些疑惑 > > 4 是JM日志 > > > 1. 去掉taskmanager-query-state-service.yaml后确实不行 nslookup > > kubectl exec -it busybox2 -- /bin/sh > / # nslookup 10.47.96.2 > Server: 10.96.0.10 > Address: 10.96.0.10:53 > > ** server can't find 2.96.47.10.in-addr.arpa: NXDOMAIN > > > > 2. Flink1.11和Flink1.10 > > detail subtasks taskmanagers xxx x 这行 > > 1.11变成了172-20-0-50。1.10是flink-taskmanager-7b5d6958b6-sfzlk:36459。这块的改动是？（目前这个集群跑着1.10和1.11,1.10可以正常运行，如果coredns有问题，1.10版本的flink应该也有一样的情况吧？） > > 3. coredns是否特殊配置？ > > 在容器中解析域名是正常的，只是反向解析没有service才会有问题。coredns是否有什么需要配置？ > > > 4. time out时候的JM日志如下： > > > > 2020-07-23 13:53:00,228 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > ResourceManager > akka.tcp://flink@flink-jobmanager:6123/user/rpc/resourcemanager_0 > was granted leadership with fencing token > 2020-07-23 13:53:00,232 INFO > org.apache.flink.runtime.rpc.akka.AkkaRpcService [] - Starting > RPC endpoint for org.apache.flink.runtime.dispatcher.StandaloneDispatcher > at akka://flink/user/rpc/dispatcher_1 . > 2020-07-23 13:53:00,233 INFO > org.apache.flink.runtime.resourcemanager.slotmanager.SlotManagerImpl [] - > Starting the SlotManager. > 2020-07-23 13:53:03,472 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > Registering TaskManager with ResourceID 1f9ae0cd95a28943a73be26323588696 > (akka.tcp://flink@10.34.128.9:6122/user/rpc/taskmanager_0) at > ResourceManager > 2020-07-23 13:53:03,777 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > Registering TaskManager with ResourceID cac09e751264e61615329c20713a84b4 > (akka.tcp://flink@10.32.160.6:6122/user/rpc/taskmanager_0) at > ResourceManager > 2020-07-23 13:53:03,787 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > Registering TaskManager with ResourceID 93c72d01d09f9ae427c5fc980ed4c1e4 > (akka.tcp://flink@10.39.0.8:6122/user/rpc/taskmanager_0) at > ResourceManager > 2020-07-23 13:53:04,044 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > Registering TaskManager with ResourceID 8adf2f8e81b77a16d5418a9e252c61e2 > (akka.tcp://flink@10.38.64.7:6122/user/rpc/taskmanager_0) at > ResourceManager > 2020-07-23 13:53:04,099 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > Registering TaskManager with ResourceID 23e9d2358f6eb76b9ae718d879d4f330 > (akka.tcp://flink@10.42.160.6:6122/user/rpc/taskmanager_0) at > ResourceManager > 2020-07-23 13:53:04,146 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > Registering TaskManager with ResourceID 092f8dee299e32df13db3111662b61f8 > (akka.tcp://flink@10.33.192.14:6122/user/rpc/taskmanager_0) at > ResourceManager > > > 2020-07-23 13:55:44,220 INFO > org.apache.flink.runtime.dispatcher.StandaloneDispatcher [] - Received > JobGraph submission 99a030d0e3f428490a501c0132f27a56 (JobTest). > 2020-07-23 13:55:44,222 INFO > org.apache.flink.runtime.dispatcher.StandaloneDispatcher [] - > Submitting job 99a030d0e3f428490a501c0132f27a56 (JobTest). > 2020-07-23 13:55:44,251 INFO > org.apache.flink.runtime.rpc.akka.AkkaRpcService [] - Starting > RPC endpoint for org.apache.flink.runtime.jobmaster.JobMaster at > akka://flink/user/rpc/jobmanager_2 . > 2020-07-23 13:55:44,260 INFO org.apache.flink.runtime.jobmaster.JobMaster > [] - Initializing job JobTest > (99a030d0e3f428490a501c0132f27a56). > 2020-07-23 13:55:44,278 INFO org.apache.flink.runtime.jobmaster.JobMaster > [] - Using restart back off time strategy > NoRestartBackoffTimeStrategy for JobTest (99a030d0e3f428490a501c0132f27a56). > 2020-07-23 13:55:44,319 INFO org.apache.flink.runtime.jobmaster.JobMaster > [] - Running initialization on master for job JobTest > (99a030d0e3f428490a501c0132f27a56). > 2020-07-23 13:55:44,319 INFO org.apache.flink.runtime.jobmaster.JobMaster > [] - Successfully
Re: Flink 1.11 submit job timed out
g slot
request [SlotRequestId{108fe0b3086567ad79275eccef2fdaf8}] timed out.
2020-07-23 14:01:18,121 INFO
org.apache.flink.runtime.jobmaster.slotpool.SlotPoolImpl [] - Pending slot
request [SlotRequestId{265e67985eab7a6dc08024e53bf2708d}] timed out.
2020-07-23 14:01:18,122 INFO
org.apache.flink.runtime.jobmaster.slotpool.SlotPoolImpl [] - Pending slot
request [SlotRequestId{7087497a17c441f1a1d6fefcbc7cd0ea}] timed out.
2020-07-23 14:01:18,122 INFO
org.apache.flink.runtime.jobmaster.slotpool.SlotPoolImpl [] - Pending slot
request [
2020-07-23 14:01:18,151 INFO
org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] -
Registering job manager
0...@akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2
for job 99a030d0e3f428490a501c0132f27a56.
2020-07-23 14:01:18,157 INFO
org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] -
Registered job manager
0...@akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2
for job 99a030d0e3f428490a501c0132f27a56.
2020-07-23 14:01:18,157 INFO
org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] -
Registered job manager
0...@akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2
for job 99a030d0e3f428490a501c0132f27a56.
2020-07-23 14:01:18,157 INFO
org.apache.flink.runtime.dispatcher.StandaloneDispatcher [] - Job
99a030d0e3f428490a501c0132f27a56 reached globally terminal state FAILED.
2020-07-23 14:01:18,162 INFO
org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] -
Registered job manager
0...@akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2
for job 99a030d0e3f428490a501c0132f27a56.
2020-07-23 14:01:18,162 INFO org.apache.flink.runtime.jobmaster.JobMaster
[] - JobManager successfully registered at ResourceManager, leader
id: .
2020-07-23 14:01:18,225 INFO org.apache.flink.runtime.jobmaster.JobMaster
[] - Stopping the JobMaster for job
JobTest(99a030d0e3f428490a501c0132f27a56).
2020-07-23 14:01:18,381 INFO
org.apache.flink.runtime.jobmaster.slotpool.SlotPoolImpl [] - Suspending
SlotPool.
2020-07-23 14:01:18,382 INFO org.apache.flink.runtime.jobmaster.JobMaster
[] - Close ResourceManager connection
83b1ff14900abfd54418e7fa3efb3f8a: JobManager is shutting down..
2020-07-23 14:01:18,382 INFO
org.apache.flink.runtime.jobmaster.slotpool.SlotPoolImpl [] - Stopping
SlotPool.
2020-07-23 14:01:18,382 INFO
org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] -
Disconnect job manager
0...@akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2
for job 99a030d0e3f428490a501c0132f27a56 from the resource manager.
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
On 07/23/2020 13:26, Yang Wang wrote:
很高兴你的问题解决了，但我觉得根本原因应该不是加上了taskmanager-query-state-service.yaml的关系。
我这边不创建这个服务也是正常的，而且nslookup {tm_ip_address}是可以正常反解析到hostname的。
注意这里不是解析hostname，而是通过ip地址来反解析进行验证
回答你说的两个问题：
1. 不是必须的，我这边验证不需要创建，集群也是可以正常运行任务的。Rest
service的暴露方式是ClusterIP、NodePort、LoadBalancer都正常
2. 如果没有配置taskmanager.bind-host，
[Flink-15911][Flink-15154]这两个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（按照官网上是可选服务）。就不会刷No
> hostname could be resolved for ip
> address，将NodePort改为ClusterIp，作业就可以成功提交，不会出现time out的问题了，问题得到了解决。
>
>
> 1. 如果按照上面的情况，那么这个配置文件是必须配置的？
>
> 2. 在1.11的更新中，发现有 [Flink-15911][Flink-15154]
> 支持分别配置用于本地监听绑定的网络接口和外部访问的地址和端口。是否是这块的改动，
> 需要JM去通过TM上报的ip反向解析出service？
>
>
> Bset！
>
>
> [1]
> https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html
>
> a511955993
> 邮箱：a511955...@163.com
>
> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1=a511955993=a511955993%40163.com=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D;
>
> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail88; 定制
>
> On 07/23/2020 10:11, Yang 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写道：
>
> >
> > Hi，Yang Wang！
> >
> > 很开心可以收到你的回复，你的回复帮助很大，让我知道了问题的方向。我再补充些信息，希望可以帮我进一步判断一下问题根源。
> >
> > 在JM报错的地方，No hostname could be resolved for ip add
Re: Flink 1.11 submit job timed out
Hi Yang Wang
刚刚在测试环境测试了一下，taskManager没有办法nslookup出来，JM可以nslookup，这两者的差别在于是否有service。
解决方案：我这边给集群加上了taskmanager-query-state-service.yaml（按照官网上是可选服务）。就不会刷No hostname
could be resolved for ip address，将NodePort改为ClusterIp，作业就可以成功提交，不会出现time
out的问题了，问题得到了解决。
1. 如果按照上面的情况，那么这个配置文件是必须配置的？
2. 在1.11的更新中，发现有 [Flink-15911][Flink-15154]
支持分别配置用于本地监听绑定的网络接口和外部访问的地址和端口。是否是这块的改动，
需要JM去通过TM上报的ip反向解析出service？
Bset！
[1]https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
On 07/23/2020 10:11, Yang 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写道：
>
> Hi，Yang Wang！
>
> 很开心可以收到你的回复，你的回复帮助很大，让我知道了问题的方向。我再补充些信息，希望可以帮我进一步判断一下问题根源。
>
> 在JM报错的地方，No hostname could be resolved for ip address x
> ，报出来的ip是k8s分配给flink pod的内网ip，不是宿主机的ip。请问这个问题可能出在哪里呢
>
> Best！
>
>
> a511955993
> 邮箱：a511955...@163.com
>
> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1=a511955993=a511955993%40163.com=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D;
>
> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail88; 定制
>
> On 07/22/2020 18:18, Yang Wang wrote:
> 如果你的日志里面一直在刷No hostname could be resolved for the IP address，应该是集群的coredns
> 有问题，由ip地址反查hostname查不到。你可以起一个busybox验证一下是不是这个ip就解析不了，有
> 可能是coredns有问题
>
>
> Best,
> Yang
>
> Congxian Qiu 于2020年7月21日周二 下午7:29写道：
>
> > Hi
> >不确定 k8s 环境中能否看到 pod 的完整日志？类似 Yarn 的 NM 日志一样，如果有的话，可以尝试看一下这个 pod
> > 的完整日志有没有什么发现
> > 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）。
> > >
> > > 在同一个环境将版本回退到1.10没有出现该问题，也不会刷如上报错。
> > >
> > >
> > > 是否有其他排查思路？
> > >
> > > Best！
> > >
> > >
> > >
> > >
> > > | |
> > > a511955993
> > > |
> > > |
> > > 邮箱：a511955...@163.com
> > > |
> > >
> > > 签名由 网易邮箱大师 定制
> > >
> > > On 07/16/2020 13:17, Congxian 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
> > > > |
> > > > |
> > > > 邮箱：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
> > > > org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No
> > > > hostname could be resolved for the IP address 10.32.160.7, using IP
> > > address
> > > > as host name. Local input split assignment (such as for HDFS files)
> may
> > > be
> > > > impacted.
> > &g
回复：flink 1.11 on kubernetes 构建失败
Hi Yang Wang！ 你提到了Flink里面用的是InetAddress#getHostFromNameService来跟进IP地址获取FQDN的。 这个在1.10和1.11版本是否有发生变化？这段报错只在1.11才出现，1.10不存在。如果core dns有问题，应该两个版本都有有异常 Best！ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 在2020年07月22日 18:18，Yang Wang 写道： 抱歉回复晚了 我这边也验证了一下，在你所说的地方确实是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写道： > hi Yang > > 在1.10版本，running的作业点击拓普图中随便一个operation，有detail subtasks taskmanagers xxx x > 这行，taskmanagers这栏里的host，显示的是 podname：端口 > > 在1.11变成ip：端口 > > 目前我这边遇到的情况是，构建了一个有120slot的集群，作业并行度是120。 提交到jm后jm就失联了，jm timeout。观察jm日志，疯狂在刷 > > > No hostname could be resolved for the IP address 10.35.160.5, using IP > address as host name. Local input split assignment (such as for HDFS files) > may be impacted > > > 目前观察到的改变主要是这块podname和ip的区别，其他不确定 > > > | | > a511955993 > | > | > 邮箱：a511955...@163.com > | > > 签名由 网易邮箱大师 定制 > > 在2020年07月10日 12:13，Yang Wang 写道： > 我记得1.11里面对host这个地方应该是没有改动，taskmanager.network.bind-policy的 > 默认值一会都是ip。所以你说的UI上是podname，这个是哪里的？正常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 address 10.35.160.5, using IP > > address as host name. Local input split assignment (such as for HDFS > files) > > may be impacted > > > > > > > > > > | | > > a511955993 > > | > > | > > 邮箱：a511955...@163.com > > | > > > > 签名由 网易邮箱大师 定制 > > > > 在2020年07月09日 20:02，Yang Wang 写道： > > sed替换报错应该不是Pod启动失败的根本原因，因为目前的docker-entrypoint.sh做了修改 > > 才会这样[1] > > > > 你这个报错看着是执行bash-java-utils.jar报的错，确认你用的是社区的yaml文件[2]，我运行是没有问题的。 > > 如果不是，需要你把你的yaml发出来 > > > > > > [1]. > > > https://github.com/apache/flink-docker/blob/dev-master/docker-entrypoint.sh > > [2]. > > > > > https://ci.apache.org/projects/flink/flink-docs-master/ops/deployment/kubernetes.html > > > > > > Best, > > Yang > > > > SmileSmile 于2020年7月9日周四 下午1:40写道： > > > > > hi > > > > > > 按照新版本的部署文件[1]，会部署失败.如果将部署文件改用1.10版本，只是修改镜像文件和log4j文件，可以成功构建[2]。 > > > > > > > > > 目前看差别在于1.11启动jm和tm是通过args: > > > > > > ["jobmanager"]的方法，通过docker-entrypoint.sh[3]看到调用set_common_options方法的时候会sed > > > 本地挂载的flink-configuration-configmap.yaml导致失败。 > > > > > > > > > 1.10 版本是通过$FLINK_HOME/bin/jobmanager.sh启动。 > > > > > > command: ["/bin/bash", "-c", "$FLINK_HOME/bin/jobmanager.sh start;\ > > > while :; > > > do > > >if [[ -f $(find log -name '*jobmanager*.log' -print -quit) > ]]; > > > then tail -f -n +1 log/*jobmanager*.log; > > >fi; > > > done"] > > > > > > > > > 如果遇到该问题的，沿用1.10版本的部署方式部署1.11镜像可以成功。 1.11 版本的部署方式如果有大佬可以走通的，求分享。 > > > > > > > > > > > > [1] > > > > > > https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html#session-cluster-resource-definitions > > > [2] > > > > > > https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/deployment/kubernetes.html#session-cluster-resource-definitions > > > [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 > > > | > > > | > > > 邮箱：a511955...@163.com > > > | > > > > > > 签名由 网易邮箱大师 定制 > > > > > > 在2020年07月08日 16:29，Yun Tang 写道： > > > Hi > > > > > > 你是不是对 /opt/flink/conf > > > 目录下的文件进行了sed相关写操作？社区文档中使用的方法是将configmap挂载成本地的flink-conf.yaml
Re: Flink 1.11 submit job timed out
Hi，Yang Wang！ 很开心可以收到你的回复，你的回复帮助很大，让我知道了问题的方向。我再补充些信息，希望可以帮我进一步判断一下问题根源。 在JM报错的地方，No hostname could be resolved for ip address x ，报出来的ip是k8s分配给flink pod的内网ip，不是宿主机的ip。请问这个问题可能出在哪里呢 Best！ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 On 07/22/2020 18:18, Yang Wang wrote: 如果你的日志里面一直在刷No hostname could be resolved for the IP address，应该是集群的coredns 有问题，由ip地址反查hostname查不到。你可以起一个busybox验证一下是不是这个ip就解析不了，有 可能是coredns有问题 Best, Yang Congxian Qiu 于2020年7月21日周二 下午7:29写道： > Hi >不确定 k8s 环境中能否看到 pod 的完整日志？类似 Yarn 的 NM 日志一样，如果有的话，可以尝试看一下这个 pod > 的完整日志有没有什么发现 > 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）。 > > > > 在同一个环境将版本回退到1.10没有出现该问题，也不会刷如上报错。 > > > > > > 是否有其他排查思路？ > > > > Best！ > > > > > > > > > > | | > > a511955993 > > | > > | > > 邮箱：a511955...@163.com > > | > > > > 签名由 网易邮箱大师 定制 > > > > On 07/16/2020 13:17, Congxian 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 > > > | > > > | > > > 邮箱：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 > > > org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No > > > hostname could be resolved for the IP address 10.32.160.7, using IP > > address > > > as host name. Local input split assignment (such as for HDFS files) may > > be > > > impacted. > > > >2020-07-15 16:58:46,460 WARN > > > org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No > > > hostname could be resolved for the IP address 10.44.224.7, using IP > > address > > > as host name. Local input split assignment (such as for HDFS files) may > > be > > > impacted. > > > >2020-07-15 16:58:46,461 WARN > > > org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No > > > hostname could be resolved for the IP address 10.40.32.9, using IP > > address > > > as host name. Local input split assignment (such as for HDFS files) may > > be > > > impacted. > > > > > > > >2020-07-15 16:59:10,236 INFO > > > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > > The > > > heartbeat of JobManager with id 69a0d460de46a9f41c770d963c0a timed > > out. > > > >2020-07-15 16:59:10,236 INFO > > > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > > > Disconnect job manager > > > @akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2 for job > > > e1554c737e37ed79688a15c746b6e9ef from the resource manager. > > > > > > > > > > > >how to deal with ？ > > > > > > > > > > > >beset ！ > > > > > > > >| | > > > >a511955993 > > > >| > > > >| > > > >邮箱：a511955...@163.com > > > >| > > > > > > > >签名由 网易邮箱大师 定制 > > > > > >
回复：flink 1.11 on kubernetes 构建失败
Hi，Yang Wang！ 很开心可以收到你的回复，你的回复帮助很大，让我知道了问题的方向。我再补充些信息，希望可以帮我进一步判断一下问题根源。 在JM报错的地方，No hostname could be resolved for ip address x ，报出来的ip是k8s分配给flink pod的内网ip，不是宿主机的ip。请问这个问题是出在哪里呢 Best！ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 在2020年07月22日 18:18，Yang Wang 写道： 抱歉回复晚了 我这边也验证了一下，在你所说的地方确实是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写道： > hi Yang > > 在1.10版本，running的作业点击拓普图中随便一个operation，有detail subtasks taskmanagers xxx x > 这行，taskmanagers这栏里的host，显示的是 podname：端口 > > 在1.11变成ip：端口 > > 目前我这边遇到的情况是，构建了一个有120slot的集群，作业并行度是120。 提交到jm后jm就失联了，jm timeout。观察jm日志，疯狂在刷 > > > No hostname could be resolved for the IP address 10.35.160.5, using IP > address as host name. Local input split assignment (such as for HDFS files) > may be impacted > > > 目前观察到的改变主要是这块podname和ip的区别，其他不确定 > > > | | > a511955993 > | > | > 邮箱：a511955...@163.com > | > > 签名由 网易邮箱大师 定制 > > 在2020年07月10日 12:13，Yang Wang 写道： > 我记得1.11里面对host这个地方应该是没有改动，taskmanager.network.bind-policy的 > 默认值一会都是ip。所以你说的UI上是podname，这个是哪里的？正常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 address 10.35.160.5, using IP > > address as host name. Local input split assignment (such as for HDFS > files) > > may be impacted > > > > > > > > > > | | > > a511955993 > > | > > | > > 邮箱：a511955...@163.com > > | > > > > 签名由 网易邮箱大师 定制 > > > > 在2020年07月09日 20:02，Yang Wang 写道： > > sed替换报错应该不是Pod启动失败的根本原因，因为目前的docker-entrypoint.sh做了修改 > > 才会这样[1] > > > > 你这个报错看着是执行bash-java-utils.jar报的错，确认你用的是社区的yaml文件[2]，我运行是没有问题的。 > > 如果不是，需要你把你的yaml发出来 > > > > > > [1]. > > > https://github.com/apache/flink-docker/blob/dev-master/docker-entrypoint.sh > > [2]. > > > > > https://ci.apache.org/projects/flink/flink-docs-master/ops/deployment/kubernetes.html > > > > > > Best, > > Yang > > > > SmileSmile 于2020年7月9日周四 下午1:40写道： > > > > > hi > > > > > > 按照新版本的部署文件[1]，会部署失败.如果将部署文件改用1.10版本，只是修改镜像文件和log4j文件，可以成功构建[2]。 > > > > > > > > > 目前看差别在于1.11启动jm和tm是通过args: > > > > > > ["jobmanager"]的方法，通过docker-entrypoint.sh[3]看到调用set_common_options方法的时候会sed > > > 本地挂载的flink-configuration-configmap.yaml导致失败。 > > > > > > > > > 1.10 版本是通过$FLINK_HOME/bin/jobmanager.sh启动。 > > > > > > command: ["/bin/bash", "-c", "$FLINK_HOME/bin/jobmanager.sh start;\ > > > while :; > > > do > > >if [[ -f $(find log -name '*jobmanager*.log' -print -quit) > ]]; > > > then tail -f -n +1 log/*jobmanager*.log; > > >fi; > > > done"] > > > > > > > > > 如果遇到该问题的，沿用1.10版本的部署方式部署1.11镜像可以成功。 1.11 版本的部署方式如果有大佬可以走通的，求分享。 > > > > > > > > > > > > [1] > > > > > > https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html#session-cluster-resource-definitions > > > [2] > > > > > > https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/deployment/kubernetes.html#session-cluster-resource-definitions > > > [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 > > > | > > > | > > > 邮箱：a511955...@163.com > > > | > > > > > > 签名由 网易邮箱大师 定制 > > > > > > 在2020年07月08日 16:29，Yun Tang 写道： > > > Hi > > > > > > 你是不是对 /opt/flink/conf > > > 目录下的文件进行了sed相关写操作？社区文档
Re: Flink 1.11 submit job timed out
Hi，Congxian 因为是测试环境，没有配置HA，目前看到的信息，就是JM刷出来大量的no hostname could be resolved，jm失联，作业提交失败。 将jm内存配置为10g也是一样的情况（jobmanager.memory.pprocesa.size：10240m）。 在同一个环境将版本回退到1.10没有出现该问题，也不会刷如上报错。 是否有其他排查思路？ Best！ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 On 07/16/2020 13:17, Congxian 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 > | > | > 邮箱：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 > org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No > hostname could be resolved for the IP address 10.32.160.7, using IP address > as host name. Local input split assignment (such as for HDFS files) may be > impacted. > >2020-07-15 16:58:46,460 WARN > org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No > hostname could be resolved for the IP address 10.44.224.7, using IP address > as host name. Local input split assignment (such as for HDFS files) may be > impacted. > >2020-07-15 16:58:46,461 WARN > org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No > hostname could be resolved for the IP address 10.40.32.9, using IP address > as host name. Local input split assignment (such as for HDFS files) may be > impacted. > > > >2020-07-15 16:59:10,236 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - The > heartbeat of JobManager with id 69a0d460de46a9f41c770d963c0a timed out. > >2020-07-15 16:59:10,236 INFO > org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - > Disconnect job manager > @akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2 for job > e1554c737e37ed79688a15c746b6e9ef from the resource manager. > > > > > >how to deal with ？ > > > > > >beset ！ > > > >| | > >a511955993 > >| > >| > >邮箱：a511955...@163.com > >| > > > >签名由 网易邮箱大师 定制 >
Re: Flink 1.11 submit job timed out
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 >org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No hostname >could be resolved for the IP address 10.32.160.7, using IP address as host >name. Local input split assignment (such as for HDFS files) may be impacted. >2020-07-15 16:58:46,460 WARN >org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No hostname >could be resolved for the IP address 10.44.224.7, using IP address as host >name. Local input split assignment (such as for HDFS files) may be impacted. >2020-07-15 16:58:46,461 WARN >org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No hostname >could be resolved for the IP address 10.40.32.9, using IP address as host >name. Local input split assignment (such as for HDFS files) may be impacted. > >2020-07-15 16:59:10,236 INFO >org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - The >heartbeat of JobManager with id 69a0d460de46a9f41c770d963c0a timed out. >2020-07-15 16:59:10,236 INFO >org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - >Disconnect job manager >0...@akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2 > for job e1554c737e37ed79688a15c746b6e9ef from the resource manager. > > >how to deal with ？ > > >beset ！ > >| | >a511955993 >| >| >邮箱：a511955...@163.com >| > >签名由 网易邮箱大师 定制
Flink 1.11 submit job timed out
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 org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No hostname could be resolved for the IP address 10.32.160.7, using IP address as host name. Local input split assignment (such as for HDFS files) may be impacted. 2020-07-15 16:58:46,460 WARN org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No hostname could be resolved for the IP address 10.44.224.7, using IP address as host name. Local input split assignment (such as for HDFS files) may be impacted. 2020-07-15 16:58:46,461 WARN org.apache.flink.runtime.taskmanager.TaskManagerLocation [] - No hostname could be resolved for the IP address 10.40.32.9, using IP address as host name. Local input split assignment (such as for HDFS files) may be impacted. 2020-07-15 16:59:10,236 INFO org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - The heartbeat of JobManager with id 69a0d460de46a9f41c770d963c0a timed out. 2020-07-15 16:59:10,236 INFO org.apache.flink.runtime.resourcemanager.StandaloneResourceManager [] - Disconnect job manager 0...@akka.tcp://flink@flink-jobmanager:6123/user/rpc/jobmanager_2 for job e1554c737e37ed79688a15c746b6e9ef from the resource manager. how to deal with ？ beset ！ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
回复：flink 1.11 on kubernetes 构建失败
hi Yang 在1.10版本，running的作业点击拓普图中随便一个operation，有detail subtasks taskmanagers xxx x 这行，taskmanagers这栏里的host，显示的是 podname：端口 在1.11变成ip：端口 目前我这边遇到的情况是，构建了一个有120slot的集群，作业并行度是120。 提交到jm后jm就失联了，jm timeout。观察jm日志，疯狂在刷 No hostname could be resolved for the IP address 10.35.160.5, using IP address as host name. Local input split assignment (such as for HDFS files) may be impacted 目前观察到的改变主要是这块podname和ip的区别，其他不确定 | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 在2020年07月10日 12:13，Yang Wang 写道： 我记得1.11里面对host这个地方应该是没有改动，taskmanager.network.bind-policy的 默认值一会都是ip。所以你说的UI上是podname，这个是哪里的？正常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 address 10.35.160.5, using IP > address as host name. Local input split assignment (such as for HDFS files) > may be impacted > > > > > | | > a511955993 > | > | > 邮箱：a511955...@163.com > | > > 签名由 网易邮箱大师 定制 > > 在2020年07月09日 20:02，Yang Wang 写道： > sed替换报错应该不是Pod启动失败的根本原因，因为目前的docker-entrypoint.sh做了修改 > 才会这样[1] > > 你这个报错看着是执行bash-java-utils.jar报的错，确认你用的是社区的yaml文件[2]，我运行是没有问题的。 > 如果不是，需要你把你的yaml发出来 > > > [1]. > https://github.com/apache/flink-docker/blob/dev-master/docker-entrypoint.sh > [2]. > > https://ci.apache.org/projects/flink/flink-docs-master/ops/deployment/kubernetes.html > > > Best, > Yang > > SmileSmile 于2020年7月9日周四 下午1:40写道： > > > hi > > > > 按照新版本的部署文件[1]，会部署失败.如果将部署文件改用1.10版本，只是修改镜像文件和log4j文件，可以成功构建[2]。 > > > > > > 目前看差别在于1.11启动jm和tm是通过args: > > > ["jobmanager"]的方法，通过docker-entrypoint.sh[3]看到调用set_common_options方法的时候会sed > > 本地挂载的flink-configuration-configmap.yaml导致失败。 > > > > > > 1.10 版本是通过$FLINK_HOME/bin/jobmanager.sh启动。 > > > > command: ["/bin/bash", "-c", "$FLINK_HOME/bin/jobmanager.sh start;\ > > while :; > > do > >if [[ -f $(find log -name '*jobmanager*.log' -print -quit) ]]; > > then tail -f -n +1 log/*jobmanager*.log; > >fi; > > done"] > > > > > > 如果遇到该问题的，沿用1.10版本的部署方式部署1.11镜像可以成功。 1.11 版本的部署方式如果有大佬可以走通的，求分享。 > > > > > > > > [1] > > > https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html#session-cluster-resource-definitions > > [2] > > > https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/deployment/kubernetes.html#session-cluster-resource-definitions > > [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 > > | > > | > > 邮箱：a511955...@163.com > > | > > > > 签名由 网易邮箱大师 定制 > > > > 在2020年07月08日 16:29，Yun Tang 写道： > > Hi > > > > 你是不是对 /opt/flink/conf > > 目录下的文件进行了sed相关写操作？社区文档中使用的方法是将configmap挂载成本地的flink-conf.yaml > > 等文件，而这个挂载的目录其实是不可写的。 > > 直接修改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 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: /docker-entrypoint.sh: cannot create > > /opt/flink/conf/flink-conf.yaml: Permission denied > > sed: couldn't open temporary file /opt/flink/conf/sedB5eynR: Read-only > > file system > > /docker-entrypoint.sh: 120: /docker-entrypoint.sh: cannot create > > /opt/flink/conf/flink-conf.yaml.tmp: Read-only file system > > [ERROR] The execution result is empty. > > [ERROR] Could not get JVM parameters and dynamic configurations properly. > > > > > > 是否有遇到同样的问题，支个招 > > > > > > > > [1] > > > https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html#session-cluster-resource-definitions > > > > > > | | > > a511955993 > > | > > | > > 邮箱：a511955...@163.com > > | > > > > 签名由 网易邮箱大师 定制 > > >
回复：flink 1.11 on kubernetes 构建失败
hi 按照新版本的部署文件[1]，会部署失败.如果将部署文件改用1.10版本，只是修改镜像文件和log4j文件，可以成功构建[2]。 目前看差别在于1.11启动jm和tm是通过args: ["jobmanager"]的方法，通过docker-entrypoint.sh[3]看到调用set_common_options方法的时候会sed 本地挂载的flink-configuration-configmap.yaml导致失败。 1.10 版本是通过$FLINK_HOME/bin/jobmanager.sh启动。 command: ["/bin/bash", "-c", "$FLINK_HOME/bin/jobmanager.sh start;\ while :; do if [[ -f $(find log -name '*jobmanager*.log' -print -quit) ]]; then tail -f -n +1 log/*jobmanager*.log; fi; done"] 如果遇到该问题的，沿用1.10版本的部署方式部署1.11镜像可以成功。 1.11 版本的部署方式如果有大佬可以走通的，求分享。 [1] https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html#session-cluster-resource-definitions [2] https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/deployment/kubernetes.html#session-cluster-resource-definitions [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 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 在2020年07月08日 16:29，Yun Tang 写道： Hi 你是不是对 /opt/flink/conf 目录下的文件进行了sed相关写操作？社区文档中使用的方法是将configmap挂载成本地的flink-conf.yaml 等文件，而这个挂载的目录其实是不可写的。 直接修改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 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: /docker-entrypoint.sh: cannot create /opt/flink/conf/flink-conf.yaml: Permission denied sed: couldn't open temporary file /opt/flink/conf/sedB5eynR: Read-only file system /docker-entrypoint.sh: 120: /docker-entrypoint.sh: cannot create /opt/flink/conf/flink-conf.yaml.tmp: Read-only file system [ERROR] The execution result is empty. [ERROR] Could not get JVM parameters and dynamic configurations properly. 是否有遇到同样的问题，支个招 [1] https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html#session-cluster-resource-definitions | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
回复：flink 1.11 on kubernetes 构建失败
hi yun tang！ 没有对 /opt/flink/config 目录下的文件做写操作。 只是按照官网上的配置文件进行部署，镜像用的也是社区的镜像。 best！ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 在2020年07月08日 16:29，Yun Tang 写道： Hi 你是不是对 /opt/flink/conf 目录下的文件进行了sed相关写操作？社区文档中使用的方法是将configmap挂载成本地的flink-conf.yaml 等文件，而这个挂载的目录其实是不可写的。 直接修改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 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: /docker-entrypoint.sh: cannot create /opt/flink/conf/flink-conf.yaml: Permission denied sed: couldn't open temporary file /opt/flink/conf/sedB5eynR: Read-only file system /docker-entrypoint.sh: 120: /docker-entrypoint.sh: cannot create /opt/flink/conf/flink-conf.yaml.tmp: Read-only file system [ERROR] The execution result is empty. [ERROR] Could not get JVM parameters and dynamic configurations properly. 是否有遇到同样的问题，支个招 [1] https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html#session-cluster-resource-definitions | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
flink 1.11 on kubernetes 构建失败
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: /docker-entrypoint.sh: cannot create /opt/flink/conf/flink-conf.yaml: Permission denied sed: couldn't open temporary file /opt/flink/conf/sedB5eynR: Read-only file system /docker-entrypoint.sh: 120: /docker-entrypoint.sh: cannot create /opt/flink/conf/flink-conf.yaml.tmp: Read-only file system [ERROR] The execution result is empty. [ERROR] Could not get JVM parameters and dynamic configurations properly. 是否有遇到同样的问题，支个招 [1] https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/deployment/kubernetes.html#session-cluster-resource-definitions | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
回复：作业升级到flink1.11，idea运行失败
添加依赖后正常了。应该是这个导致的
https://ci.apache.org/projects/flink/flink-docs-master/release-notes/flink-1.11.html#reversed-dependency-from-flink-streaming-java-to-flink-client-flink-15090
thanks
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月08日 11:30，Yangze Guo 写道：
尝试加一下这个依赖
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
> ExecutorFactory found to execute the application.
> at
> org.apache.flink.core.execution.DefaultExecutorServiceLoader.getExecutorFactory(DefaultExecutorServiceLoader.java:84)
> at
> org.apache.flink.streaming.api.environment.StreamExecutionEnvironment.executeAsync(StreamExecutionEnvironment.java:1803)
> at
> org.apache.flink.streaming.api.environment.StreamExecutionEnvironment.execute(StreamExecutionEnvironment.java:1713)
> at
> org.apache.flink.streaming.api.environment.LocalStreamEnvironment.execute(LocalStreamEnvironment（）
>
> 是哪里出问题了呢
> | |
> a511955993
> |
> |
> 邮箱：a511955...@163.com
> |
>
> 签名由 网易邮箱大师 定制
作业升级到flink1.11，idea运行失败
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 org.apache.flink.streaming.api.environment.StreamExecutionEnvironment.executeAsync(StreamExecutionEnvironment.java:1803) at org.apache.flink.streaming.api.environment.StreamExecutionEnvironment.execute(StreamExecutionEnvironment.java:1713) at org.apache.flink.streaming.api.environment.LocalStreamEnvironment.execute(LocalStreamEnvironment（） 是哪里出问题了呢 | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
回复：rocksdb的block cache usage应该如何使用
hi yun tang！
下午通过配置yaml的方式修改env成功生成内存文件，目前在重新复现和获取文件ing！ tanks！具体内存dump在获取ing
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月07日 17:47，Yun Tang 写道：
Hi
你的jemalloc有带debug的重新编译么? 例如用下面的命令重新编译jemalloc得到相关的so文件
./configure --enable-prof --enable-stats --enable-debug --enable-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: 回复：rocksdb的block cache usage应该如何使用
hi yun tang！
我在容器内加入了libjemalloc.so.2并且在配置中加上了
containerized.master.env.LD_PRELOAD: "/opt/jemalloc/lib/libjemalloc.so.2"
containerized.master.env.MALLOC_CONF:
"prof:true,lg_prof_interval:25,lg_prof_sample:17"
请问要如何可以得到内存文件？试着kill一个tm，找不到对应的heap文件。求助
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 19:13，Yun Tang 写道：
hi
有采集过内存使用情况么，推荐使用jemalloc的预先加载方式[1][2]来sample
JVM的内存使用，观察是否有malloc的内存存在超用的场景。需要配置相关参数
containerized.taskmanager.env.MALLOC_CONF 和
containerized.taskmanager.env.LD_PRELOAD
[1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%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了，只会重启，没有恢复历史数据。
【作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。】
我目前遇到的情况是作业fail重启，pod就很容易被os kill，只能重构集群解决。
详情可见
http://apache-flink.147419.n8.nabble.com/Checkpoint-td4406.html
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 15:13，Yun Tang 写道：
Hi
如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。
祝好
唐云
________
From: SmileSmile
Sent: Friday, July 3, 2020 15:07
To: Yun Tang
Cc: user-zh@flink.apache.org
Subject: 回复：rocksdb的block cache usage应该如何使用
hi yun tang！
因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os
kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。
从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？
<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1=a511955993=a511955993%40163.com=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D;
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：a511955...@163.com
签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88; 定制
在2020年07月03日 14:59，Yun Tang<mailto:myas...@live.com> 写道：
Hi
观察block cache 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
Subject: 回复：rocksdb的block cache usage应该如何使用
thanks yun tang！
那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os
kill的情况，想对比下
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 14:10，Yun Tang 写道：
Hi
默认Flink启用了rocksDB 的managed
memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block
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应该如何使用
通过 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
ui上显示的Flink Managed MEM是8.48G。
通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host)
如果维度是host，operator_name，每个operator_name维度是22G。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host,operator_name)
请问这个指标应该如何使用？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
jemalloc dump 内存
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文件， /opt/state挂载在宿主机的磁盘上，权限给了。 请问该如何操作才可以生产内存dump呢？ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
回复：rocksdb的block cache usage应该如何使用
hi yun tang！
我在容器内加入了libjemalloc.so.2并且在配置中加上了
containerized.master.env.LD_PRELOAD: "/opt/jemalloc/lib/libjemalloc.so.2"
containerized.master.env.MALLOC_CONF:
"prof:true,lg_prof_interval:25,lg_prof_sample:17"
请问要如何可以得到内存文件？试着kill一个tm，找不到对应的heap文件。求助
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 19:13，Yun Tang 写道：
hi
有采集过内存使用情况么，推荐使用jemalloc的预先加载方式[1][2]来sample
JVM的内存使用，观察是否有malloc的内存存在超用的场景。需要配置相关参数
containerized.taskmanager.env.MALLOC_CONF 和
containerized.taskmanager.env.LD_PRELOAD
[1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%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了，只会重启，没有恢复历史数据。
【作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。】
我目前遇到的情况是作业fail重启，pod就很容易被os kill，只能重构集群解决。
详情可见
http://apache-flink.147419.n8.nabble.com/Checkpoint-td4406.html
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 15:13，Yun Tang 写道：
Hi
如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。
祝好
唐云
________
From: SmileSmile
Sent: Friday, July 3, 2020 15:07
To: Yun Tang
Cc: user-zh@flink.apache.org
Subject: 回复：rocksdb的block cache usage应该如何使用
hi yun tang！
因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os
kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。
从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？
<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1=a511955993=a511955993%40163.com=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D;
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：a511955...@163.com
签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88; 定制
在2020年07月03日 14:59，Yun Tang<mailto:myas...@live.com> 写道：
Hi
观察block cache 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
Subject: 回复：rocksdb的block cache usage应该如何使用
thanks yun tang！
那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os
kill的情况，想对比下
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 14:10，Yun Tang 写道：
Hi
默认Flink启用了rocksDB 的managed
memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block
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应该如何使用
通过 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
ui上显示的Flink Managed MEM是8.48G。
通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host)
如果维度是host，operator_name，每个operator_name维度是22G。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host,operator_name)
请问这个指标应该如何使用？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
回复：rocksdb的block cache usage应该如何使用
Hi
作业只配置了重启策略，作业如果fail了，只会重启，没有恢复历史数据。
【作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。】
我目前遇到的情况是作业fail重启，pod就很容易被os kill，只能重构集群解决。
详情可见
http://apache-flink.147419.n8.nabble.com/Checkpoint-td4406.html
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 15:13，Yun Tang 写道：
Hi
如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。
祝好
唐云
From: SmileSmile
Sent: Friday, July 3, 2020 15:07
To: Yun Tang
Cc: user-zh@flink.apache.org
Subject: 回复：rocksdb的block cache usage应该如何使用
hi yun tang！
因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os
kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。
从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？
<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1=a511955993=a511955993%40163.com=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D;
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：a511955...@163.com
签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88; 定制
在2020年07月03日 14:59，Yun Tang<mailto:myas...@live.com> 写道：
Hi
观察block cache 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
Subject: 回复：rocksdb的block cache usage应该如何使用
thanks yun tang！
那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os
kill的情况，想对比下
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 14:10，Yun Tang 写道：
Hi
默认Flink启用了rocksDB 的managed
memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block
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应该如何使用
通过 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
ui上显示的Flink Managed MEM是8.48G。
通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host)
如果维度是host，operator_name，每个operator_name维度是22G。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host,operator_name)
请问这个指标应该如何使用？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
回复：rocksdb的block cache usage应该如何使用
hi yun tang！
因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os
kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。
从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 14:59，Yun Tang 写道：
Hi
观察block cache 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
Subject: 回复：rocksdb的block cache usage应该如何使用
thanks yun tang！
那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os
kill的情况，想对比下
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 14:10，Yun Tang 写道：
Hi
默认Flink启用了rocksDB 的managed
memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block
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应该如何使用
通过 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
ui上显示的Flink Managed MEM是8.48G。
通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host)
如果维度是host，operator_name，每个operator_name维度是22G。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host,operator_name)
请问这个指标应该如何使用？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
回复：rocksdb的block cache usage应该如何使用
thanks yun tang！
那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os
kill的情况，想对比下
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
在2020年07月03日 14:10，Yun Tang 写道：
Hi
默认Flink启用了rocksDB 的managed
memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block
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应该如何使用
通过 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
ui上显示的Flink Managed MEM是8.48G。
通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host)
如果维度是host，operator_name，每个operator_name维度是22G。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host,operator_name)
请问这个指标应该如何使用？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
回复：在没有开启Checkpoint的情况下，当作业重启时，历史数据是否会残留在内存中？
作业运行在k8s上，这个现象可以重现，目前我这边有多份数据join的作业基本都会有这个问题。步骤如下： 1. 使用eventtime，水位线设置为数据时间-3分钟，状态使用rocksdb，不开启checkpoint，设置内存limit 2. 作业运行一段时间。 3. kill 其中一个pod，作业fail 4. k8s自动拉起该pod，观察其他pod的内存使用，会上涨。运行一段时间然后很容易超过limit被os kill 5. 陷入被重复kill的死循环。 解决方法：销毁集群，重构即可。 观察过heap的内存，没有问题。 被os kill怀疑是offheap超用，offheap没有正常释放。 有一个疑问，如果没有开启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() > 的clearAllState实现清理，如果作业重启，又没有开启checkpoint，尚未被处理的历史数据是否一直残留在内存中无法清理？ > > > 是否有哪位大佬可以帮忙解惑？ > > | | > a511955993 > | > | > 邮箱：a511955...@163.com > | > > 签名由 网易邮箱大师 定制
回复：在没有开启Checkpoint的情况下，当作业重启时，历史数据是否会残留在内存中？
这种现象只会出现在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() 的clearAllState实现清理，如果作业重启，又没有开启checkpoint，尚未被处理的历史数据是否一直残留在内存中无法清理？ 是否有哪位大佬可以帮忙解惑？ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
在没有开启Checkpoint的情况下，当作业重启时，历史数据是否会残留在内存中？
Hi 我的作业是运行在1.10.1, 使用的是event time ，没有开启checkPoint。每当作业重启一次，container memory usage会上涨2G，每重启一次就会上涨一些内存直到被OS kill。 历史数据的清理是在新event time到达之后调用 WindowOperator#onEventTime() 的clearAllState实现清理，如果作业重启，又没有开启checkpoint，尚未被处理的历史数据是否一直残留在内存中无法清理？ 是否有哪位大佬可以帮忙解惑？ | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制
rocksdb的block cache usage应该如何使用
通过 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
ui上显示的Flink Managed MEM是8.48G。
通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host)
如果维度是host，operator_name，每个operator_name维度是22G。
sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"})
by (host,operator_name)
请问这个指标应该如何使用？
| |
a511955993
|
|
邮箱：a511955...@163.com
|
签名由 网易邮箱大师 定制
??????????????????restart????????OOM
oommetaspace ??os kill?? | | a511955993 | | ??a511955...@163.com | ?? ??2020??07??01?? 11:32??kcz ?? 1.10.0??1.11.0classloader?? OK??OOMmetaspaceOOM?? ---- ??:""https://issues.apache.org/jira/browse/FLINK-11205 SmileSmile
回复：作业因为异常restart后，频繁OOM
作业如果正常运行，堆外内存是足够的。在restart后才会出现频繁重启的情况，重构集群才能恢复正常 | | a511955993 | | 邮箱：a511955...@163.com | 签名由 网易邮箱大师 定制 在2020年06月30日 23:39，LakeShen 写道： 我在较低版本，Flink on k8s ，也遇到 OOM 被 kill 了。 我感觉可能是 TaskManager 堆外内存不足了，我目前是 Flink 1.6 版本，Flink on k8s , standalone per job 模式，堆外内存默认没有限制~。 我的解决方法增加了一个参数：taskmanager.memory.off-heap: true. 目前来看，OOM被 kill 掉的问题没有在出现了。希望能帮到你。 Best, LakeShen SmileSmile 于2020年6月30日周二 下午11:19写道： > > 补充一下，内核版本为 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。 > > > 目前遇到的问题是作业如果因为网络抖动或者硬件故障导致的pod被失联而fail，在pod重生后，作业自动restart，作业运行一段时间（半小时到1小时不等）很容易出现其他pod因为oom被os > kill的现象，然后反复循环，pod 被kill越来越频繁。目前的解决方法是手动销毁这个集群，重新构建一个集群后重启作业，就恢复正常。 > > > 如果单纯heap的状态后台，作业restart不会出现这样的问题。 > > > 有一些不成熟的猜测，作业在fail后，native memory没有释放干净，pod的limit假设为10G，那么job > restart后只有8G，TM还是按照10G的标准运行，pod使用的内存就会超过10G而被os kill（纯属猜测）。 > > > 请问大家是否有什么好的提议或者解决方法？ > > > 其中一次系统内核日志如下： > > > Jun 30 21:59:15 flink-tm-1 kernel: memory: usage 28672000kB, limit > 28672000kB, failcnt 11225 > Jun 30 21:59:15 flink-tm-1 kernel: memory+swap: usage 28672000kB, limit > 9007199254740988kB, failcnt 0 > Jun 30 21:59:15 flink-tm-1 kernel: kmem: usage 0kB, limit > 9007199254740988kB, failcnt 0 > Jun 30 21:59:15 flink-tm-1 kernel: Memory cgroup stats for > /kubepods.slice/kubepods-pod5ad5d2ea_5faa_4a11_96b4_39271ab76e99.slice: > cache:0KB rss:0KB rss_huge:0KB mapped_file:0KB swap:0K > B inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB > unevictable:0KB > Jun 30 21:59:15 flink-tm-1 kernel: Memory cgroup stats for > /kubepods.slice/kubepods-pod5ad5d2ea_5faa_4a11_96b4_39271ab76e99.slice/docker-fe101418a3b2a7c534e89b4ac73d29b04070eb923220a5b1 > 7338850bbdb3817a.scope: cache:0KB rss:44KB rss_huge:0KB mapped_file:0KB > swap:0KB inactive_anon:0KB active_anon:44KB inactive_file:0KB > active_file:0KB unevictable:0KB > Jun 30 21:59:15 flink-tm-1 kernel: Memory cgroup stats for > /kubepods.slice/kubepods-pod5ad5d2ea_5faa_4a11_96b4_39271ab76e99.slice/docker-a2295e812a828738810a8f1ae69cd48e99ef98b9e1038158a6e33f81524cc02a.scope: > cache:180KB rss:28671776KB rss_huge:26437632KB mapped_file:144KB swap:0KB > inactive_anon:0KB active_anon:28671760KB inactive_file:4KB active_file:4KB > unevictable:0KB > Jun 30 21:59:15 flink-tm-1 kernel: [ pid ] uid tgid total_vm rss > nr_ptes swapents oom_score_adj name > Jun 30 21:59:15 flink-tm-1 kernel: [16875] 0 16875 2531 > 40 -998 pause > Jun 30 21:59:15 flink-tm-1 kernel: [17274] 0 17274 1369 421 > 70 -998 bash > Jun 30 21:59:15 flink-tm-1 kernel: [18089] 0 18089 10824832 7174316 > 145000 -998 java > Jun 30 21:59:15 flink-tm-1 kernel: [18348] 0 18348 1017 196 > 60 -998 tail > Jun 30 21:59:15 flink-tm-1 kernel: Memory cgroup out of memory: Kill > process 26824 (Window(Tumbling) score 4 or sacrifice child > Jun 30 21:59:15 flink-tm-1 kernel: Killed process 18089 (java) > total-vm:43299328kB, anon-rss:28669084kB, file-rss:28180kB, shmem-rss:0kB > > > > > > > Looking forward to your reply and help. > > Best
回复：作业因为异常restart后，频繁OOM
补充一下，内核版本为 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。 目前遇到的问题是作业如果因为网络抖动或者硬件故障导致的pod被失联而fail，在pod重生后，作业自动restart，作业运行一段时间（半小时到1小时不等）很容易出现其他pod因为oom被os kill的现象，然后反复循环，pod 被kill越来越频繁。目前的解决方法是手动销毁这个集群，重新构建一个集群后重启作业，就恢复正常。 如果单纯heap的状态后台，作业restart不会出现这样的问题。 有一些不成熟的猜测，作业在fail后，native memory没有释放干净，pod的limit假设为10G，那么job restart后只有8G，TM还是按照10G的标准运行，pod使用的内存就会超过10G而被os kill（纯属猜测）。 请问大家是否有什么好的提议或者解决方法？ 其中一次系统内核日志如下： Jun 30 21:59:15 flink-tm-1 kernel: memory: usage 28672000kB, limit 28672000kB, failcnt 11225 Jun 30 21:59:15 flink-tm-1 kernel: memory+swap: usage 28672000kB, limit 9007199254740988kB, failcnt 0 Jun 30 21:59:15 flink-tm-1 kernel: kmem: usage 0kB, limit 9007199254740988kB, failcnt 0 Jun 30 21:59:15 flink-tm-1 kernel: Memory cgroup stats for /kubepods.slice/kubepods-pod5ad5d2ea_5faa_4a11_96b4_39271ab76e99.slice: cache:0KB rss:0KB rss_huge:0KB mapped_file:0KB swap:0K B inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB Jun 30 21:59:15 flink-tm-1 kernel: Memory cgroup stats for /kubepods.slice/kubepods-pod5ad5d2ea_5faa_4a11_96b4_39271ab76e99.slice/docker-fe101418a3b2a7c534e89b4ac73d29b04070eb923220a5b1 7338850bbdb3817a.scope: cache:0KB rss:44KB rss_huge:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:44KB inactive_file:0KB active_file:0KB unevictable:0KB Jun 30 21:59:15 flink-tm-1 kernel: Memory cgroup stats for /kubepods.slice/kubepods-pod5ad5d2ea_5faa_4a11_96b4_39271ab76e99.slice/docker-a2295e812a828738810a8f1ae69cd48e99ef98b9e1038158a6e33f81524cc02a.scope: cache:180KB rss:28671776KB rss_huge:26437632KB mapped_file:144KB swap:0KB inactive_anon:0KB active_anon:28671760KB inactive_file:4KB active_file:4KB unevictable:0KB Jun 30 21:59:15 flink-tm-1 kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name Jun 30 21:59:15 flink-tm-1 kernel: [16875] 0 16875 2531 40 -998 pause Jun 30 21:59:15 flink-tm-1 kernel: [17274] 0 17274 1369 421 70 -998 bash Jun 30 21:59:15 flink-tm-1 kernel: [18089] 0 18089 10824832 7174316 145000 -998 java Jun 30 21:59:15 flink-tm-1 kernel: [18348] 0 18348 1017 196 60 -998 tail Jun 30 21:59:15 flink-tm-1 kernel: Memory cgroup out of memory: Kill process 26824 (Window(Tumbling) score 4 or sacrifice child Jun 30 21:59:15 flink-tm-1 kernel: Killed process 18089 (java) total-vm:43299328kB, anon-rss:28669084kB, file-rss:28180kB, shmem-rss:0kB Looking forward to your reply and help. Best
