rocksdb的block cache usage应该如何使用

[Chris Guo]

通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Yun Tang]

Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Chris Guo]

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Yun Tang]

Hi

观察block cache usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory / slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os kill，使用的是从savepoint恢复数据么？

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 14:20
To: Yun Tang <[hidden email]>
Cc: Flink user-zh mailing list <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Chris Guo]

hi yun tang！

因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。

从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？





| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:59，Yun Tang 写道：
Hi

观察block cache usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory / slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os kill，使用的是从savepoint恢复数据么？

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 14:20
To: Yun Tang <[hidden email]>
Cc: Flink user-zh mailing list <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Yun Tang]

Hi

如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:07
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

hi yun tang！

因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。

从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？




<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=a511955993&uid=a511955993%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D>
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：[hidden email]

签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88> 定制

在2020年07月03日 14:59，Yun Tang<mailto:[hidden email]> 写道：
Hi

观察block cache usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory / slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os kill，使用的是从savepoint恢复数据么？

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 14:20
To: Yun Tang <[hidden email]>
Cc: Flink user-zh mailing list <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Chris Guo]

Hi

作业只配置了重启策略，作业如果fail了，只会重启，没有恢复历史数据。

【作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。】
我目前遇到的情况是作业fail重启，pod就很容易被os kill，只能重构集群解决。

详情可见
http://apache-flink.147419.n8.nabble.com/Checkpoint-td4406.html


| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 15:13，Yun Tang 写道：
Hi

如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:07
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

hi yun tang！

因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。

从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？




<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=a511955993&uid=a511955993%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D&gt;
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：[hidden email]

签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88&gt; 定制

在2020年07月03日 14:59，Yun Tang<mailto:[hidden email]> 写道：
Hi

观察block cache usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory / slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os kill，使用的是从savepoint恢复数据么？

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 14:20
To: Yun Tang <[hidden email]>
Cc: Flink user-zh mailing list <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Yun Tang]

hi

有采集过内存使用情况么，推荐使用jemalloc的预先加载方式[1][2]来sample JVM的内存使用，观察是否有malloc的内存存在超用的场景。需要配置相关参数 containerized.taskmanager.env.MALLOC_CONF 和 containerized.taskmanager.env.LD_PRELOAD


[1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
[2] https://www.evanjones.ca/java-native-leak-bug.html

祝好
唐云


________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:22
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

Hi

作业只配置了重启策略，作业如果fail了，只会重启，没有恢复历史数据。

【作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。】
我目前遇到的情况是作业fail重启，pod就很容易被os kill，只能重构集群解决。

详情可见
http://apache-flink.147419.n8.nabble.com/Checkpoint-td4406.html


| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 15:13，Yun Tang 写道：
Hi

如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:07
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

hi yun tang！

因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。

从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？




<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=a511955993&uid=a511955993%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D&gt;
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：[hidden email]

签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88&gt; 定制

在2020年07月03日 14:59，Yun Tang<mailto:[hidden email]> 写道：
Hi

观察block cache usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory / slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os kill，使用的是从savepoint恢复数据么？

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 14:20
To: Yun Tang <[hidden email]>
Cc: Flink user-zh mailing list <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Chris Guo]

hi yun tang！

我在容器内加入了libjemalloc.so.2并且在配置中加上了
containerized.master.env.LD_PRELOAD: "/opt/jemalloc/lib/libjemalloc.so.2"
containerized.master.env.MALLOC_CONF: "prof:true,lg_prof_interval:25,lg_prof_sample:17"

请问要如何可以得到内存文件？试着kill一个tm，找不到对应的heap文件。求助



| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 19:13，Yun Tang 写道：
hi

有采集过内存使用情况么，推荐使用jemalloc的预先加载方式[1][2]来sample JVM的内存使用，观察是否有malloc的内存存在超用的场景。需要配置相关参数 containerized.taskmanager.env.MALLOC_CONF 和 containerized.taskmanager.env.LD_PRELOAD


[1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
[2] https://www.evanjones.ca/java-native-leak-bug.html

祝好
唐云


________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:22
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

Hi

作业只配置了重启策略，作业如果fail了，只会重启，没有恢复历史数据。

【作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。】
我目前遇到的情况是作业fail重启，pod就很容易被os kill，只能重构集群解决。

详情可见
http://apache-flink.147419.n8.nabble.com/Checkpoint-td4406.html


| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 15:13，Yun Tang 写道：
Hi

如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:07
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

hi yun tang！

因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。

从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？




<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=a511955993&uid=a511955993%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D&gt;
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：[hidden email]

签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88&gt; 定制

在2020年07月03日 14:59，Yun Tang<mailto:[hidden email]> 写道：
Hi

观察block cache usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory / slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os kill，使用的是从savepoint恢复数据么？

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 14:20
To: Yun Tang <[hidden email]>
Cc: Flink user-zh mailing list <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Yun Tang]

Hi

你的jemalloc有带debug的重新编译么? 例如用下面的命令重新编译jemalloc得到相关的so文件
./configure --enable-prof --enable-stats --enable-debug --enable-fill
make

其次最好指定dump文件的输出地址，例如在 MALLOC_CONF中加上前缀的配置  prof_prefix:/tmp/jeprof.out ，以确保文件位置可写。

最后，由于你是在容器中跑，在容器退出前要保证相关文件能上传或者退出时候hang住一段时间，否则相关dump的文件无法看到了

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Monday, July 6, 2020 14:15
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

hi yun tang！

我在容器内加入了libjemalloc.so.2并且在配置中加上了
containerized.master.env.LD_PRELOAD: "/opt/jemalloc/lib/libjemalloc.so.2"
containerized.master.env.MALLOC_CONF: "prof:true,lg_prof_interval:25,lg_prof_sample:17"

请问要如何可以得到内存文件？试着kill一个tm，找不到对应的heap文件。求助



| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 19:13，Yun Tang 写道：
hi

有采集过内存使用情况么，推荐使用jemalloc的预先加载方式[1][2]来sample JVM的内存使用，观察是否有malloc的内存存在超用的场景。需要配置相关参数 containerized.taskmanager.env.MALLOC_CONF 和 containerized.taskmanager.env.LD_PRELOAD


[1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
[2] https://www.evanjones.ca/java-native-leak-bug.html

祝好
唐云


________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:22
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

Hi

作业只配置了重启策略，作业如果fail了，只会重启，没有恢复历史数据。

【作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。】
我目前遇到的情况是作业fail重启，pod就很容易被os kill，只能重构集群解决。

详情可见
http://apache-flink.147419.n8.nabble.com/Checkpoint-td4406.html


| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 15:13，Yun Tang 写道：
Hi

如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:07
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

hi yun tang！

因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。

从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？




<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=a511955993&uid=a511955993%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D&gt;
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：[hidden email]

签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88&gt; 定制

在2020年07月03日 14:59，Yun Tang<mailto:[hidden email]> 写道：
Hi

观察block cache usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory / slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os kill，使用的是从savepoint恢复数据么？

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 14:20
To: Yun Tang <[hidden email]>
Cc: Flink user-zh mailing list <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

[Chris Guo]

hi yun tang！

下午通过配置yaml的方式修改env成功生成内存文件，目前在重新复现和获取文件ing！ tanks！具体内存dump在获取ing



| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月07日 17:47，Yun Tang 写道：
Hi

你的jemalloc有带debug的重新编译么? 例如用下面的命令重新编译jemalloc得到相关的so文件
./configure --enable-prof --enable-stats --enable-debug --enable-fill
make

其次最好指定dump文件的输出地址，例如在 MALLOC_CONF中加上前缀的配置  prof_prefix:/tmp/jeprof.out ，以确保文件位置可写。

最后，由于你是在容器中跑，在容器退出前要保证相关文件能上传或者退出时候hang住一段时间，否则相关dump的文件无法看到了

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Monday, July 6, 2020 14:15
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

hi yun tang！

我在容器内加入了libjemalloc.so.2并且在配置中加上了
containerized.master.env.LD_PRELOAD: "/opt/jemalloc/lib/libjemalloc.so.2"
containerized.master.env.MALLOC_CONF: "prof:true,lg_prof_interval:25,lg_prof_sample:17"

请问要如何可以得到内存文件？试着kill一个tm，找不到对应的heap文件。求助



| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 19:13，Yun Tang 写道：
hi

有采集过内存使用情况么，推荐使用jemalloc的预先加载方式[1][2]来sample JVM的内存使用，观察是否有malloc的内存存在超用的场景。需要配置相关参数 containerized.taskmanager.env.MALLOC_CONF 和 containerized.taskmanager.env.LD_PRELOAD


[1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
[2] https://www.evanjones.ca/java-native-leak-bug.html

祝好
唐云


________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:22
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

Hi

作业只配置了重启策略，作业如果fail了，只会重启，没有恢复历史数据。

【作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。】
我目前遇到的情况是作业fail重启，pod就很容易被os kill，只能重构集群解决。

详情可见
http://apache-flink.147419.n8.nabble.com/Checkpoint-td4406.html


| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 15:13，Yun Tang 写道：
Hi

如果是没有开启Checkpoint，作业是如何做到failover的？failover的时候一定需要从Checkpoint加载数据的。还是说你其实开启了Checkpoint，但是Checkpoint的interval设置的很大，所以每次failover相当于作业重新运行。
如果都没有从checkpoint加载数据，哪里来的历史数据呢？作业一旦发生failover，state backend的数据都需要清空然后再启动的时候进行加载。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 15:07
To: Yun Tang <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

hi yun tang！

因为网络或者不可抗力导致pod重生，作业会重启，目前作业没有开启checkpoint，恢复等价继续消费最新数据计算，运行一段时间很容易内存超用被os kill，然后重启，再运行一段时间，间隔变短，死的越来越频繁。

从现象上看很像是内存没有释放，这种场景下，上一次作业残留的未到水位线还没有被触发计算的数据是否在作业重启过程中被清除了？




<https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=a511955993&uid=a511955993%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Aa511955993%40163.com%22%5D&gt;
[https://mail-online.nosdn.127.net/qiyelogo/defaultAvatar.png]
a511955993
邮箱：[hidden email]

签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail88&gt; 定制

在2020年07月03日 14:59，Yun Tang<mailto:[hidden email]> 写道：
Hi

观察block cache usage的显示数值是否超过你的单个slot的managed memory，计算方法是 managed memory / slot数目，得到一个slot的managed memory，将该数值与block cache usage比较，看内存是否超用。重启之后容易被os kill，使用的是从savepoint恢复数据么？

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Friday, July 3, 2020 14:20
To: Yun Tang <[hidden email]>
Cc: Flink user-zh mailing list <[hidden email]>
Subject: 回复：rocksdb的block cache usage应该如何使用

thanks yun tang！

那如果想通过block cache usage判断是否超过managed memory，该如何配置呢？ 最近遇到作业只要重启后很容易被os kill的情况，想对比下




| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制

在2020年07月03日 14:10，Yun Tang 写道：
Hi

默认Flink启用了rocksDB 的managed memory，这里涉及到这个功能的实现原理，简单来说，一个slot里面的所有rocksDB实例底层“托管”内存的LRU block cache均是一个，这样你可以根据taskmanager和subtask_index 作为tag来区分，你会发现在同一个TM里面的某个subtask对应的不同column_family 的block cache的数值均是完全相同的。所以不需要将这个数值进行求和统计。

祝好
唐云
________________________________
From: SmileSmile <[hidden email]>
Sent: Thursday, July 2, 2020 18:05
To: Flink user-zh mailing list <[hidden email]>
Subject: rocksdb的block cache usage应该如何使用


通过 state.backend.rocksdb.metrics.block-cache-usage: true开启 rocksdb_block_cache_usage监控，上报到prometheus，对应的指标名称是
flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage。


我们的作业一个TM的内存设置如下：

taskmanager.memory.process.size: 23000m
taskmanager.memory.managed.fraction: 0.4

ui上显示的Flink Managed MEM是8.48G。


通过grafana配置出来的图，如果group by的维度是host，得出来的每个TM在作业稳定后是45G，超过8.48G了。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host)



如果维度是host，operator_name，每个operator_name维度是22G。

sum(flink_taskmanager_job_task_operator_window_contents_rocksdb_block_cache_usage{reportName=~"$reportName"}) by (host,operator_name)


请问这个指标应该如何使用？

| |
a511955993
|
|
邮箱：[hidden email]
|

签名由 网易邮箱大师 定制