看现象是这样，谢了，我抽空看下这块源码
| |
吴先生
|
|
15951914...@163.com
|
回复的原邮件
| 发件人 | Zakelly Lan |
| 发送日期 | 2024年1月11日 16:33 |
| 收件人 | |
| 主题 | Re: flink-checkpoint 问题 |
看了下代码，这个问题有可能的原因是：
1. flink是先创建chk目录，然后再打 Triggering checkpoint 的 log
的，所以有概率是目录创建了，但是log没输出trigger
2. 作业失败，和触发下一个cp，这是两个异步线程，所以有可能
748)
checkpoing路径下有：
25546：正常
25547：无
25548：有，路径下为空
任务人为从25548恢复时失败，抛出异常找不到_metadate文件
| |
吴先生
|
|
15951914...@163.com
|
回复的原邮件
| 发件人 | Xuyang |
| 发送日期 | 2024年1月11日 14:55 |
| 收件人 | |
| 主题 | Re:回复： flink-checkpoint 问题 |
Hi, 你的图挂了，可以用图床处理一下，或者直接贴log。
--
Best！
Xuyang
在 2024-01-11 13
JM中chk失败时间点日志，没有25548的触发记录：
自动recovery失败：
TM日志：
checkpoint文件路径，25548里面空的：
| |
吴先生
|
|
15951914...@163.com
|
回复的原邮件
| 发件人 | Zakelly Lan |
| 发送日期 | 2024年1月10日 18:20 |
| 收件人 | |
| 主题 | Re: flink-checkpoint 问题 |
你好，
方便的话贴一下jobmanager的log吧，应该有一些线索
On Wed, Jan 10, 2024 at 5:55 PM 吴先
Flink版本： 1.12
checkpoint配置：hdfs
现象：作业由于一些因素第N个checkpoint失败，导致任务重试，任务重试失败，hdfs中不存在第N个chk路径，但是为什么会出现一个第N+1的chk路径，且这个路径下是空的
请问好使吗，怎么使用的
| |
吴先生
|
|
15951914...@163.com
|
回复的原邮件
| 发件人 | allanqinjy |
| 发送日期 | 2023年8月30日 20:02 |
| 收件人 | user-zh@flink.apache.org |
| 主题 | 回复：flink-metrics如何获取applicationid |
多谢了，明天改一下代码试试
回复的原邮件
| 发件人 | Feng Jin |
| 发送日期 | 2023年08月30日 19:42 |
| 收件人 | user-zh |
| 主题 | Re
ivate static final long serialVersionUID = 1L;
private Sum() {
}
public Long reduce(Long value1, Long value2) throws Exception {
return value1 + value2;
}
}
}
| |
吴先生
|
|
15951914...@163.com
|
好的感谢，我关注下
| |
吴先生
|
|
15951914...@163.com
|
回复的原邮件
| 发件人 | Shammon FY |
| 发送日期 | 2023年3月13日 18:49 |
| 收件人 | |
| 主题 | Re: Flink-Sql Watermarkers问题 |
Hi
目前sql只能在create table时指定，不过有新的扩展功能，相关FLIP正在讨论中，你可以关注一下
https://cwiki.apache.org/confluence/display/FLINK/FLIP-296%3A+Extend+watermark
hi，
我在使用Flink-Sql 1.14版本时能否不在create table处指定watermarkers，因为源数据需要做一些清洗之后再指定水位线
| |
吴先生
|
|
15951914...@163.com
|
感谢，我看下
| |
吴先生
|
|
15951914...@163.com
|
回复的原邮件
| 发件人 | Weihua Hu |
| 发送日期 | 2023年3月3日 10:37 |
| 收件人 | |
| 主题 | Re: Flink内存问题 |
Hi,
针对问题 2， 可以增加下列环境变量来排除 Glibc 的问题，详情可以参考[1]
containerized.master.env.MALLOC_ARENA_MAX: 1
containerized.taskmanager.env.MALLOC_ARENA_MAX: 1
[1]
https
Hi,
目前分析问题应该在堆外，大概率是managed和overhead这两部分，这两部分的内存分配比例都是默认配置，通过网上的相关资料来看有两种解决方案：
1、调大managed和overhead这两块的内存比例，
问题：调整多大合适？是否调整之后还会持续增长
2、还有另一种说法是glibc内存分配器有个64M的问题引起（这里可有深入研究），替换为jemalloc可避免
问题：有具体的知道方案吗
| |
吴先生
|
|
15951914...@163.com
|
回复的原邮件
| 发件人 | Shammon FY |
| 发送日期 | 2023年3月2日 19
=container_e02_1654567136606_1034_01_12] is running
745472B beyond the 'PHYSICAL' memory limit. Current usage: 8.0 GB of 8 GB
physical memory used; 10.0 GB of 40 GB virtual memory used. Killing container.
请问：
该如何排查及优化
| |
吴先生
|
|
15951914...@163.com
|
11 matches
Mail list logo
