You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@flink.apache.org by Luna Wong <gf...@gmail.com> on 2020/11/24 07:19:40 UTC

FlinkSQL导致Prometheus内存暴涨

FlinkSQL 生成的Metrics数据 task_name名字超长,导致Prometheus查询的时候内存暴涨,生产环境接受不了。
下面只是一个最简单的例子,复杂的SQL生成的task_name长达9000字节。这会导致Prometheus内存暴涨,我该怎么办。

task_name="Source:_wuren_foo_ods_foo____SourceConversion_table__Unregistered_DataStream_1___fields__id__name______SinkConversionToRow____SourceConversion_table__default_catalog_default_database_ods_foo___fields__id__name__PROCTIME______Calc_select__id__name______SinkConversionToTuple2____Sink:_Unnamed"

Re: FlinkSQL导致Prometheus内存暴涨

Posted by Luna Wong <gf...@gmail.com>.
我看了源码了。operator name截断了。但是task name没截断。task name是那些operator name拼起来的
所以特别长。现在我只是魔改源码临时截断了一下,咱还是在issue里讨论吧

Jark Wu <im...@gmail.com> 于2020年11月26日周四 下午8:53写道:
>
> IIRC, runtime will truncate the operator name to max 80 characters, see
> `TaskMetricGroup#METRICS_OPERATOR_NAME_MAX_LENGTH`.
> You can search the log if there are "The operator name {} exceeded the {}
> characters length limit and was truncated.".
>
> On Thu, 26 Nov 2020 at 18:18, hailongwang <18...@163.com> wrote:
>
> >
> >
> >
> > Hi,
> >  是的,个人觉得可以提供一个配置项来控制 task Name。
> >  完整的 task name 有助于排查问题等,简短的 task name 有助于在生产环境中 metric
> > 的采集,可以极大较少发送的网络开销,存储空间等。
> >  已建立个了 issue :https://issues.apache.org/jira/browse/FLINK-20375
> >
> >
> > Best,
> > Hailong
> >
> > 在 2020-11-24 14:19:40,"Luna Wong" <gf...@gmail.com> 写道:
> > >FlinkSQL 生成的Metrics数据 task_name名字超长,导致Prometheus查询的时候内存暴涨,生产环境接受不了。
> > >下面只是一个最简单的例子,复杂的SQL生成的task_name长达9000字节。这会导致Prometheus内存暴涨,我该怎么办。
> > >
> >
> > >task_name="Source:_wuren_foo_ods_foo____SourceConversion_table__Unregistered_DataStream_1___fields__id__name______SinkConversionToRow____SourceConversion_table__default_catalog_default_database_ods_foo___fields__id__name__PROCTIME______Calc_select__id__name______SinkConversionToTuple2____Sink:_Unnamed"
> >

Re: FlinkSQL导致Prometheus内存暴涨

Posted by Jark Wu <im...@gmail.com>.
IIRC, runtime will truncate the operator name to max 80 characters, see
`TaskMetricGroup#METRICS_OPERATOR_NAME_MAX_LENGTH`.
You can search the log if there are "The operator name {} exceeded the {}
characters length limit and was truncated.".

On Thu, 26 Nov 2020 at 18:18, hailongwang <18...@163.com> wrote:

>
>
>
> Hi,
>  是的,个人觉得可以提供一个配置项来控制 task Name。
>  完整的 task name 有助于排查问题等,简短的 task name 有助于在生产环境中 metric
> 的采集,可以极大较少发送的网络开销,存储空间等。
>  已建立个了 issue :https://issues.apache.org/jira/browse/FLINK-20375
>
>
> Best,
> Hailong
>
> 在 2020-11-24 14:19:40,"Luna Wong" <gf...@gmail.com> 写道:
> >FlinkSQL 生成的Metrics数据 task_name名字超长,导致Prometheus查询的时候内存暴涨,生产环境接受不了。
> >下面只是一个最简单的例子,复杂的SQL生成的task_name长达9000字节。这会导致Prometheus内存暴涨,我该怎么办。
> >
>
> >task_name="Source:_wuren_foo_ods_foo____SourceConversion_table__Unregistered_DataStream_1___fields__id__name______SinkConversionToRow____SourceConversion_table__default_catalog_default_database_ods_foo___fields__id__name__PROCTIME______Calc_select__id__name______SinkConversionToTuple2____Sink:_Unnamed"
>

Re:FlinkSQL导致Prometheus内存暴涨

Posted by hailongwang <18...@163.com>.


Hi,
 是的,个人觉得可以提供一个配置项来控制 task Name。
 完整的 task name 有助于排查问题等,简短的 task name 有助于在生产环境中 metric 的采集,可以极大较少发送的网络开销,存储空间等。
 已建立个了 issue :https://issues.apache.org/jira/browse/FLINK-20375


Best,
Hailong

在 2020-11-24 14:19:40,"Luna Wong" <gf...@gmail.com> 写道:
>FlinkSQL 生成的Metrics数据 task_name名字超长,导致Prometheus查询的时候内存暴涨,生产环境接受不了。
>下面只是一个最简单的例子,复杂的SQL生成的task_name长达9000字节。这会导致Prometheus内存暴涨,我该怎么办。
>
>task_name="Source:_wuren_foo_ods_foo____SourceConversion_table__Unregistered_DataStream_1___fields__id__name______SinkConversionToRow____SourceConversion_table__default_catalog_default_database_ods_foo___fields__id__name__PROCTIME______Calc_select__id__name______SinkConversionToTuple2____Sink:_Unnamed"