大家好,
我们在 YARN 容器内运行以 RocksDB 作为 State Backend 的 Flink 作业,状态数据比较大(50G
以上,难以放到内存中)。但是由于 YARN 本身的 pmem-check 限制,经常会因为内存用量的不受控而导致整个 Container 被强制
KILL.
目前调研了 https://issues.apache.org/jira/browse/FLINK-7289 这个提议,但是目前还未完全实现。
也按照 RocksDB 官方的调优指南
https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-G
https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-metrics-size-all-mem-tables
> > [2]
> >
> https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/config.html#state-backend-rocksdb-metrics-block-cache-usage
> > [3]
Hi,
近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
做时间格式化为字符串时,默认以 UTC+0 为准。
长期以来,TableConfig 类里面有一个 setLocalTimeZone 方法;将其设置为东八区以后,发现格式化后的字符串仍然是 UTC+0
的。而深入来看,Flink 的时间格式化时的代码生成逻辑(time.scala)并未考虑时区的设置。
由于大多数用户的时区均不是 UTC+0(GMT、UTC),如果时间格式化、显示等都可以考虑到 TableConfig 中的时区设置,那么 Flink
是否会更
Hi,
建议使用 Profiling 工具查看下堆内内存的使用情况,或者使用 MAT
等内存泄漏分析工具,找出具体的瓶颈所在(有可能是用户自定义的数据结构导致的问题)。如果发现堆内占用不大,则可能是堆外内存(native
部分)导致的,那么也可以用 jemalloc 和 jeprof 等工具来辅助定位。
On Mon, Mar 23, 2020 at 10:12 PM faaron zheng wrote:
>
> 大家好,我在用flink1.10执行sql时,当数据比较大的时候,3T左右,100多亿条数据,在执行hash和sort的时候经常超出内存限制,被yarn杀掉,我的tm给了
和UTC+0 一致)。
>
> 你的需求可以通过 CONVERT_TZ(timestamp_string, time_zone_from_string,
> time_zone_to_string)
>
> *Best Regards,*
> *Zhenghua Gao*
>
>
> On Mon, Mar 23, 2020 at 10:12 PM DONG, Weike
> wrote:
>
> > Hi,
> >
> > 近期发现 Flink 的 Blink Planner 在 DATE_FORMAT
Hi,
我们也遇到了同样的问题,并行度增加后,JobManager 卡住的时间越来越长,直到所有的 TaskManager 都被迫超时了。目前来看和 GC
无关,网络这里嫌疑更大。
On Fri, Jul 31, 2020 at 7:55 PM Matt Wang wrote:
> 遇到了同样的问题,也是启动了 taskmanager-query-state-service.yaml
> 这个服务后,作业才能正常提交的,另外我是在本地装的 k8s 集群进行测试的,如果是 GC 的问题,启不启动 TM service 应该不会有影响的
>
>
> --
>
> Best,
> Matt
Hi 大家好,
近期在处理 LEFT JOIN 语句时,发现了一个奇怪的现象:假设有如下 SQL 语句:
CREATE TABLE A (
key INT
) WITH (
'connector' = 'kafka',
);
CREATE TABLE B (
key INT
) WITH (
'connector' = 'kafka',
);
CREATE TABLE Sink (
id INTEGER,
upsert_value BIGINT,
primary key (`id`) NOT ENFORCED
) WITH (