yarn，我已经关闭了yarn的内存检查，glibc的那个参数已经配置成1了
Weihua Hu 于2023年4月21日周五 19:23写道：
> Hi,
>
> 你作业运行在 YARN 还是 Kubernetes 上？可以先关注下文档里的 Glibc 泄露问题
>
> Best,
> Weihua
>
>
> On Fri, Apr 21, 2023 at 6:04 PM Guo Thompson
> wrote:
>
> > Flink
> >
> Job是基于sql的，Flink版
Flink
Job是基于sql的，Flink版本为1.13.3，state用rocksDB存，发现会存在内存泄露的情况，作业运行一段时间后，会被linux内核kill掉，求助，如何解决？
网上
http://www.whitewood.me/2021/01/02/%E8%AF%A6%E8%A7%A3-Flink-%E5%AE%B9%E5%99%A8%E5%8C%96%E7%8E%AF%E5%A2%83%E4%B8%8B%E7%9A%84-OOM-Killed/
讲很可能就是rocksDB的内存没法回收导致。
1、分配 tm的30G内存，jvm堆内的远远没有使用完。
[image:
可能是jm 和 tm之间的心跳时间太短了， dump的过程会stop the world，tm就不响应jm的heartbeat了；
lxk 于2023年2月14日周二 14:32写道：
> Flink version:1.16
> java version: jdk1.8.0_251
> 问题：最近上线的Flink程序，频繁young
> gc，几秒一次，在调整了新生代大小之后，还是没有解决，目前整个jvm堆大小是3.57g。因此想通过程序内存情况来分析哪里问题有问题，我们通过yarn上的applicationId,使用ps
> -ef|grep
感觉是tm gc太久导致的
Weihua Hu 于2022年11月2日周三 19:47写道：
> Hi,
> 这种情况一般是这两个 TaskManager 出现故障断开连接了。可以再查看下之前的日志验证下。
>
> Best,
> Weihua
>
>
> On Wed, Nov 2, 2022 at 9:41 AM casel.chen wrote:
>
> > 今天线上 Flink 1.13.2 作业遇到如下报错，请问是何原因，要如何解决？
> > 作业内容是从kafka topic消费canal json数据写到另一个mysql库表
> >
> >
> >
各个chunk 边拉取, 边emit到下游
郑 致远 于2022年11月4日周五 15:27写道：
> 请教大佬, flink cdc 全量拉取阶段, 会等所有的chunk 都拉取成功后, 才output到下游吗?
>
> 还是说 各个chunk 边拉取, 边emit到下游?
>
基于yarn的多并行度，其实是落在不同的机器，当然，这么大的状态，RocksDB肯定会罗盘，是不是只有上SSD和多磁盘读写，靠硬件来优化了?
Yun Tang 于2022年4月2日周六 16:35写道：
> Hi,
>
> 200GB 这么大规模的单机state，其实没有什么很好的优化途径了，因为这个时候基本就得落盘，比拼的就是操作系统的page
> cache和磁盘的IO能力。
>
> 祝好
> 唐云
> ________
> From: Guo Thompson
> Se
看不到图
赵旭晨 于2022年3月15日周二 12:25写道：
> flink版本：1.14.3 场景如下：
> sql：
> set table.exec.state.ttl=1 day;
> describe t_k_chargeorder;
> describe t_k_appointment;
> SELECT
> ReportTime,
> sum( InsertAppointmentCount ) + sum( InsertChargeOrderCount )
> kpitotalcount,
> sum( InsertActualPriceCount )
难道条件还不会下推么？
Peihui He 于2022年3月31日周四 10:33写道：
> Hi, all
>
> 请教下大家，使用flink jdbc 读取tidb中数据时如何在查询的时候能否根据条件在数据库层面做一些过滤呢？
> 当数据量很大比如几千万上亿的话，flink jdbc source 就很无力了。
>
>
> Best Regards!
>
可以参考jdbc-connector写mysql的思路，在java里面用hashMap来存，key为 order_id
，然后定时把map的数据刷mysql
18703416...@163.com <18703416...@163.com> 于2022年3月1日周二 14:40写道：
> 首先确定 source 事件有 eventTime ，比如 source 的返回类型为 MySource
> 示例代码如下:
> static class MySource {
> Long ts;
> String key;
> Object object;
> }
>
hbase和es的数据是怎么实时同步的？
潘明文 于2022年3月1日周二 19:07写道：
> HI,
>现在环境是CDH
> 集群6台下，elasticsearch作为hbase二级索引，如何优化代码使得通过elasticsearch二级索引再查询hbase数据速度优化到0.1秒一下。谢谢。
>
>
>
>
>
如果rocksDB的状态很大呢？例如：200G，这种开了火焰图经常发现瓶颈也是在rocksDB的get（），这种有优化思路么？
Yun Tang 于2022年3月21日周一 14:42写道：
> Hi,
>
> RocksDB 的CPU栈能卡在100%，很有可能是大量解压缩 index/filter block导致的，可以enable partition
> index/filter [1] 看看问题是否解决。
> 相关内容也可以参考我之前线下做过的分享 [2]
>
>
> [1]
>
入口：
[image: image.png]
批量处理：
[image: image.png]
刷盘：
executeBatch按理来讲就是mysql的一个事务。
[image: image.png]
*疑惑：从flush中可以看到，底层是分开了两个executeBatch，举一个例子：*
*kafka里面消息从flink-cdc通过debizium采集出来，对update的mysql操作会对应两条消息(op:d,op:c)，这时候如果d和c两条消息在不同的executor中，在不同的executeBatch，会不会导致乱序？最终丢数据？？*
-- Forwarded message -
发件人： Guo Thompson
Date: 2022年2月28日周一 16:39
Subject: flink-connector-jdbc sink mysql是否会存在乱序问题
To: user-zh
入口：
[image: image.png]
批量处理：
[image: image.png]
刷盘：
executeBatch按理来讲就是mysql的一个事务。
[image: image.png]
*疑惑：从flush中可以看到，底层是分开了两个executeBatch，举一个例子
要指定savepoint的目录，不然不会从历史状态恢复
enginegun 于2022年2月28日周一 16:38写道：
> flink 重启任务 进行状态恢复是否必须指定checkpoint目录，能否默认读取最后一次生成的checkpoint 进行状态恢复？
应该是checkpoint的时候就会提交kafka 的offset
kcz <573693...@qq.com.invalid> 于2021年12月30日周四 14:54写道：
> 有一个问题请教下大佬们，学迷糊了，
> 用了flink-1.14.0版本，开启了chk(500ms做一次)，精准一次消费，事件时间
> source（kafka）- (1min的window，到时之后开始做count计算) - sink(mysql)
> 生产几条数据给kafka，但是没有超过窗口的1分钟触发时间，观察到了kafka偏移量被提交了。
>
15 matches
Mail list logo
