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 (
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,
>
和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,
建议使用 Profiling 工具查看下堆内内存的使用情况，或者使用 MAT
等内存泄漏分析工具，找出具体的瓶颈所在（有可能是用户自定义的数据结构导致的问题）。如果发现堆内占用不大，则可能是堆外内存（native
部分）导致的，那么也可以用 jemalloc 和 jeprof 等工具来辅助定位。
On Mon, Mar 23, 2020 at 10:12 PM faaron zheng wrote:
>
>
Hi,
近期发现 Flink 的 Blink Planner 在 DATE_FORMAT 对 CURRENT_TIMESTAMP
做时间格式化为字符串时，默认以 UTC+0 为准。
长期以来，TableConfig 类里面有一个 setLocalTimeZone 方法；将其设置为东八区以后，发现格式化后的字符串仍然是 UTC+0
的。而深入来看，Flink 的时间格式化时的代码生成逻辑（time.scala）并未考虑时区的设置。
由于大多数用户的时区均不是 UTC+0（GMT、UTC），如果时间格式化、显示等都可以考虑到 TableConfig 中的时区设置，那么 Flink
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]
大家好，
我们在 YARN 容器内运行以 RocksDB 作为 State Backend 的 Flink 作业，状态数据比较大（50G
以上，难以放到内存中）。但是由于 YARN 本身的 pmem-check 限制，经常会因为内存用量的不受控而导致整个 Container 被强制
KILL.
目前调研了 https://issues.apache.org/jira/browse/FLINK-7289 这个提议，但是目前还未完全实现。
也按照 RocksDB 官方的调优指南
