谢谢大佬，我再去看看gc log
-- 原始邮件 --
发件人: Xintong Song
成功了 欢迎多发问题咨询
了不起的盖茨比 <573693...@qq.com> 于2020年4月29日周三 下午12:16写道：
>
full GC 应该不是增大内存后才出现的，这一点可以确认一下 GC log。但是增大内存，可能会造成一次 full GC 花费的时间更长，从而导致
TM 心跳超时。
同样的，metaspace OOM 也可能是由于 GC 速度变慢造成的。JVM 有单独的线程负责 GC，通常是在
heap/direct/metaspace 这些区域用满之前达到某个阈值就开始 GC，如果 GC 速度慢于内存申请的速度，也有可能造成 OOM。
按照我们的经验，一个 TM 用 64G 也是比较大了，如果都是以 java heap 内存为主的话，那可能需要具体配一下 GC 策略。
Thank you~
memoryfull
gc??taskmanager??job??metaspace??
fullgc??
----
??:"Xintong
Hi all:
最近在使用flink sql 做一些计算任务，发现如果一条sql被解析成execute
plan后可能会有多个job，但是这些job的并行度是一样的，目前来看，好像还不能对这些job进行并行度的调整，请问一下大家，有什么办法可能调整sql解析后的job的并行度呢？
java.lang.OutOfMemoryError: unable to create newnative
thread??XmxMaxDirectMemorySize??
----
??:"LakeShen"http://apache-flink.147419.n8.nabble.com/flink-kafka-td2386.html
[2]
Metaspace OOM 通常是 JVM 加载的类过多导致的。TM 内存从 1568m 增大到 65536m，是否有增加 slot
的数量呢？这个有可能造成运行时加载的类变多，metaspace 大小不变的情况下也可能会触发 OOM。
目前社区已经收到许多反馈，关于 1.10.0 的默认 metaspace 大小可能不太合理，在 1.10.1 中会调大这个默认值。你这边也可以先把
taskmanager.memory.metaspace.size 调到 256m 试一试。
Thank you~
Xintong Song
On Tue, Apr 28, 2020 at 7:21
大家好，本文为 Flink Weekly 的第十四期，由李本超整理、云邪Review。主要内容包括：近期社区开发进展，邮件问题答疑以及 Flink
最新社区动态及技术文章推荐。
DEVRelease
Dian Fu 宣布 1.9.3 发布
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/ANNOUNCE-Apache-Flink-1-9-3-released-td40730.html
Yu Li 发起了1.10.1 RC1 的投票
好的 感谢
| |
王志华
|
|
a15733178...@163.com
|
签名由网易邮箱大师定制
在2020年04月29日 10:29，Junzhong Qin 写道：
可以试一下Jsoniter, https://jsoniter.com/index.cn.html
阿华田 于2020年4月29日周三 上午10:07写道：
这个确实排查到了，主要是json解析那块耗时，老版本用的gson，现在改成fastjson了，解析速度提升了不少。看来大数据量的json解析还得是fastjson
| |
王志华
|
|
a15733178...@163.com
|
可以试一下Jsoniter, https://jsoniter.com/index.cn.html
阿华田 于2020年4月29日周三 上午10:07写道：
>
> 这个确实排查到了，主要是json解析那块耗时，老版本用的gson，现在改成fastjson了，解析速度提升了不少。看来大数据量的json解析还得是fastjson
>
>
> | |
> 王志华
> |
> |
> a15733178...@163.com
> |
> 签名由网易邮箱大师定制
>
>
> 在2020年04月29日 10:02，LakeShen 写道：
> Hi 阿华,
>
>
Hi 首维，
你用的 Flink 版本是多少呢，然后你的 Checkpoint interval 设置的时间是多少，这两个信息提供一下。
Best,
LakeShen
刘首维 于2020年4月28日周二 下午6:28写道：
> Hi all,
>
>
>
> 今天发现有一个作业日志中连续打印下面这个报警
>
> "Committing offsets to Kafka takes longer than the checkpoint interval.
> Skipping commit of previous offsets because newer complete
这个确实排查到了，主要是json解析那块耗时，老版本用的gson，现在改成fastjson了，解析速度提升了不少。看来大数据量的json解析还得是fastjson
| |
王志华
|
|
a15733178...@163.com
|
签名由网易邮箱大师定制
在2020年04月29日 10:02，LakeShen 写道：
Hi 阿华,
数据延迟有可能是逻辑中某个环节比较耗时，比如查询 mysql，或者某处逻辑较复杂等等。
可以看看自己代码中，有么有比较耗时的逻辑。同时可以将自己认为比较耗时的地方，加上日志，看下处理时间。
Best,
LakeShen
阿华田
Hi 阿华,
数据延迟有可能是逻辑中某个环节比较耗时，比如查询 mysql，或者某处逻辑较复杂等等。
可以看看自己代码中，有么有比较耗时的逻辑。同时可以将自己认为比较耗时的地方，加上日志，看下处理时间。
Best,
LakeShen
阿华田 于2020年4月29日周三 上午9:21写道：
> 好的 感谢大佬
>
>
>
> | |
> 王志华
> |
> |
> a15733178...@163.com
> |
> 签名由网易邮箱大师定制
>
>
> 在2020年04月29日 09:08，zhisheng 写道：
> hi,
>
>
好的 感谢大佬
| |
王志华
|
|
a15733178...@163.com
|
签名由网易邮箱大师定制
在2020年04月29日 09:08，zhisheng 写道：
hi,
数据延迟不一定会产生背压，举个例子，Flink 写 HBase 的作业，Source 并行度为 5，Sink 并行度
10，这种情况下游写入速度很快的，可能写入速度超过 Flink 消费 Kafka 的速度，这种情况就不会出现背压的问题。
1、建议排查一下作业的并行度（可以设置和 Kafka 分区数一样）；
2、背压监控是通过 Flink Web UI 监控查看的，还是通过指标来判断的？
hi,
数据延迟不一定会产生背压，举个例子，Flink 写 HBase 的作业，Source 并行度为 5，Sink 并行度
10，这种情况下游写入速度很快的，可能写入速度超过 Flink 消费 Kafka 的速度，这种情况就不会出现背压的问题。
1、建议排查一下作业的并行度（可以设置和 Kafka 分区数一样）；
2、背压监控是通过 Flink Web UI 监控查看的，还是通过指标来判断的？
3、对于数据延迟建议还是得对 Kafka 消费的 Topic 进行消费组的监控，加上 Lag 告警，这样可以及时知道数据延迟情况
Best ！
zhisheng
阿华田
??:124G??
taskmanager.memory.process.size: 65536m
es5-connector sink
??fullgc java.lang.OutOfMemoryError: Metaspace
taskmanager.memory.process.size: 1568m
es5-connector sink
Hi all,
今天发现有一个作业日志中连续打印下面这个报警
"Committing offsets to Kafka takes longer than the checkpoint interval.
Skipping commit of previous offsets because newer complete checkpoint offsets
are available. This does not compromise Flink's checkpoint integrity."
导致作业卡住无法继续消费Kafka topic
col1 col2 pid
1.0 2.0 1
2.0 2.0 1
1.0 2.0 1
3.0 2.0 1
1.0 2.0 1
1.0 2.0 2
1.0 2.0 2
1.0 2.0 2
1.0 2.0 2
1.0 2.0 2
各位大神，想问一下利用flink dataset 对pid 列进行分组，然后对分组后的col1列的内容进行拼接，如1.0#2.0#1.0#3.0
请问大家这个该怎么实现？
结果的正确性问题？我不太明白。比如我的结果是
(true,(Mary,1))
(true,(Bob,1))
(false,(Mary,1))
(true,(Mary,2))
(true,(Liz,1))
(false,(Bob,1))
(true,(Bob,2))
我只做upsert好像没什么问题。针对retract流处理没问题；
其实我还是不太明白 upsert 流
在2020年4月28日 14:34，Jark Wu 写道：
是能提高一定的效率。不过可能会导致结果正确性问题。
Best,
Jark
On Tue, 28 Apr 2020 at 14:16, 1101300123
如果我的sink是mysql 支持主键索引，我可不可以理解处理逻辑是retract
和upsert是一样的；上游数据false标记的是失效的记录，我删除失效的或者更新失效的数据是无区别的；
其实我还是对retract流和upsert流有点疑问
https://ci.apache.org/projects/flink/flink-docs-release-1.10/zh/dev/table/streaming/dynamic_tables.html
Append-only stream: A dynamic table that is only modified by
是能提高一定的效率。不过可能会导致结果正确性问题。
Best,
Jark
On Tue, 28 Apr 2020 at 14:16, 1101300123 wrote:
> 我知道，我的意思是，upsert自己实现了，我可以直接丢弃false的数据不做处理这样会不会提升部分效率
>
>
> 在2020年4月28日 14:11，Jark Wu 写道：
> UpsertSink 仍然可能会收到 delete 消息的，所以你可以看到 UpsertSink 的输入是 Tuple2
> ，当 false 时代表 delelte，true 时代表 upsert 消息。
>
> Best,
>
我知道，我的意思是，upsert自己实现了，我可以直接丢弃false的数据不做处理这样会不会提升部分效率
在2020年4月28日 14:11，Jark Wu 写道：
UpsertSink 仍然可能会收到 delete 消息的，所以你可以看到 UpsertSink 的输入是 Tuple2
，当 false 时代表 delelte，true 时代表 upsert 消息。
Best,
Jark
On Tue, 28 Apr 2020 at 14:05, 1101300123 wrote:
我看源码这样写道:
/**
* Get dialect upsert statement,
UpsertSink 仍然可能会收到 delete 消息的，所以你可以看到 UpsertSink 的输入是 Tuple2
，当 false 时代表 delelte，true 时代表 upsert 消息。
Best,
Jark
On Tue, 28 Apr 2020 at 14:05, 1101300123 wrote:
> 我看源码这样写道:
> /**
> * Get dialect upsert statement, the database has its own upsert syntax,
> such as Mysql
> * using DUPLICATE KEY
我看源码这样写道:
/**
* Get dialect upsert statement, the database has its own upsert syntax, such
as Mysql
* using DUPLICATE KEY UPDATE, and PostgresSQL using ON CONFLICT... DO UPDATE
SET..
*
* @return None if dialect does not support upsert statement, the writer will
degrade to
* the use of
25 matches
Mail list logo
