【Flink精讲】Flink性能调优:CPU核数与并行度

2024-02-26 14:52

本文主要是介绍【Flink精讲】Flink性能调优:CPU核数与并行度,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

常见问题

举个例子

提交任务命令:

bin/flink run \
-t yarn-per-job \
-d \
-p 5 \ 指定并行度
-Dyarn.application.queue=test \ 指定 yarn 队列
-Djobmanager.memory.process.size=2048mb \ JM2~4G 足够
-Dtaskmanager.memory.process.size=4096mb \ 单个 TM2~8G 足够
-Dtaskmanager.numberOfTaskSlots=2 \ 与容器核数 1core: 1slot 或 2core: 1slot
-c com.atguigu.flink.tuning.UvDemo \
/opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar

并行度为5,每个任务占用槽数为2,则需要申请3个容器(2*3=6),JobManager需要一个容器,共需要4个容器。6个vcore+JobManager的1个vcore共7个vcore。而实际上是4个容器,4个vcore,这是为什么呢?

实际运行效果: 

Yarn调度器设置

这跟yarn的调度器设置相关,找到capacity-scheduler.xml

  • default的方式只会参考内存来申请容器,不会考虑cpu的需求。
  • 调整为下面domian的方式,会综合考虑内存+CPU的需求来申请资源。

调整后运行效果:

刷新一下

 指定容器核心数

bin/flink run \
-t yarn-per-job \
-d \
-p 5 \
-Drest.flamegraph.enabled=true \
-Dyarn.application.queue=test \
-Dyarn.containers.vcores=3 \
-Djobmanager.memory.process.size=1024mb \
-Dtaskmanager.memory.process.size=4096mb \
-Dtaskmanager.numberOfTaskSlots=2 \
-c com.atguigu.flink.tuning.UvDemo \
/opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar

一个容器3个核,2个slot,不是1:1的关系也可以。

slot主要隔离内存,不隔离cpu资源。

solt还有一个共享机制,一个slot可以同时跑多个task,一个solt可以不只使用一个线程。

通常让系统自动来设置,通常跟solt数1比1

并行度设置

  1. 配置文件:默认并行度,默认1
  2. 提交参数:如-p 5
  3. 代码env
  4. 代码算子

优先级下面的高。

全局并行度计算

        开发完成后,先进行压测。任务并行度给 10 以下,测试单个并行度的处理上限。然后
总QPS / 单并行度的处理能力 = 并行度
QPS使用高峰期的。
        开发完 Flink 作业,压测的方式很简单,先在 kafka 中积压数据,之后开启 Flink 任务,
出现反压,就是处理瓶颈。相当于水库先积水,一下子泄洪。
        不能只从 QPS 去得出并行度,因为有些字段少、逻辑简单的任务,单并行度一秒处理
几万条数据。 而有些数据字段多,处理逻辑复杂, 单并行度一秒只能处理 1000 条数据。
最好根据高峰期的 QPS 压测, 并行度*1.2 倍,富余一些资源。

查看单个任务的输出量:numRecordsOutPerSecond,单并行度7000条/秒,生成环境高峰期的qps:30000/s,30000/7000 = 4.x,并行度5,再乘以个冗余1.2 = 6个

如果数据源是kafka,可以按kafka分区数来设置并行度。 

大部分情况下并行度10以下即可。

Source 端并行度的配置

        数据源端是 Kafka, Source 的并行度设置为 Kafka 对应 Topic 的分区数。
        如果已经等于 Kafka 的分区数, 消费速度仍跟不上数据生产速度, 考虑下 Kafka 要扩
大分区, 同时调大并行度等于分区数。

        Flink 的一个并行度可以处理一至多个分区的数据,如果并行度多于 Kafka 的分区数,
那么就会造成有的并行度空闲,浪费资源。

Transform 端并行度的配置

Keyby 之前的算子

一般不会做太重的操作,都是比如 map、 filter、 flatmap 等处理较快的算子,并行度
可以和 source 保持一致。

Keyby 之后的算子

如果并发较大,建议设置并行度为 2 的整数次幂,例如: 128、 256、 512;
小并发任务的并行度不一定需要设置成 2 的整数次幂;
大并发任务如果没有 KeyBy,并行度也无需设置为 2 的整数次幂;

Sink 端并行度的配置

        Sink 端是数据流向下游的地方,可以根据 Sink 端的数据量及下游的服务抗压能力进行评估。 如果 Sink 端是 Kafka,可以设为 Kafka 对应 Topic 的分区数。
        Sink 端的数据量小, 比较常见的就是监控告警的场景,并行度可以设置的小一些。
        Source 端的数据量是最小的,拿到 Source 端流过来的数据后做了细粒度的拆分,数据量不断的增加,到 Sink 端的数据量就非常大。那么在 Sink 到下游的存储中间件的时候就需要提高并行度。
        另外 Sink 端要与下游的服务进行交互,并行度还得根据下游的服务抗压能力来设置,如果在 Flink Sink 这端的数据量过大的话, 且 Sink 处并行度也设置的很大,但下游的服务完全撑不住这么大的并发写入,可能会造成下游服务直接被写挂,所以最终还是要在 Sink处的并行度做一定的权衡。

这篇关于【Flink精讲】Flink性能调优:CPU核数与并行度的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/749228

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

性能测试介绍

性能测试是一种测试方法,旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试,可以确定系统是否能够满足预期的性能要求,找出性能瓶颈和潜在的问题,并进行优化和调整。 发现性能瓶颈:性能测试可以帮助发现系统的性能瓶颈,即系统在高负载或高并发情况下可能出现的问题

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

黑神话,XSKY 星飞全闪单卷性能突破310万

当下,云计算仍然是企业主要的基础架构,随着关键业务的逐步虚拟化和云化,对于块存储的性能要求也日益提高。企业对于低延迟、高稳定性的存储解决方案的需求日益迫切。为了满足这些日益增长的 IO 密集型应用场景,众多云服务提供商正在不断推陈出新,推出具有更低时延和更高 IOPS 性能的云硬盘产品。 8 月 22 日 2024 DTCC 大会上(第十五届中国数据库技术大会),XSKY星辰天合正式公布了基于星

从状态管理到性能优化:全面解析 Android Compose

文章目录 引言一、Android Compose基本概念1.1 什么是Android Compose?1.2 Compose的优势1.3 如何在项目中使用Compose 二、Compose中的状态管理2.1 状态管理的重要性2.2 Compose中的状态和数据流2.3 使用State和MutableState处理状态2.4 通过ViewModel进行状态管理 三、Compose中的列表和滚动

JVM内存调优原则及几种JVM内存调优方法

JVM内存调优原则及几种JVM内存调优方法 1、堆大小设置。 2、回收器选择。   1、在对JVM内存调优的时候不能只看操作系统级别Java进程所占用的内存,这个数值不能准确的反应堆内存的真实占用情况,因为GC过后这个值是不会变化的,因此内存调优的时候要更多地使用JDK提供的内存查看工具,比如JConsole和Java VisualVM。   2、对JVM内存的系统级的调优主要的目的是减少

PR曲线——一个更敏感的性能评估工具

在不均衡数据集的情况下,精确率-召回率(Precision-Recall, PR)曲线是一种非常有用的工具,因为它提供了比传统的ROC曲线更准确的性能评估。以下是PR曲线在不均衡数据情况下的一些作用: 关注少数类:在不均衡数据集中,少数类的样本数量远少于多数类。PR曲线通过关注少数类(通常是正类)的性能来弥补这一点,因为它直接评估模型在识别正类方面的能力。 精确率与召回率的平衡:精确率(Pr

Flink任务重启策略

概述 Flink支持不同的重启策略,以在故障发生时控制作业如何重启集群在启动时会伴随一个默认的重启策略,在没有定义具体重启策略时会使用该默认策略。如果在工作提交时指定了一个重启策略,该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被使用。常用的重启策略: 固定间隔 (Fixe

Java程序到CPU上执行 的步骤

相信很多的小伙伴在最初学习编程的时候会容易产生一个疑惑❓,那就是编写的Java代码究竟是怎么一步一步到CPU上去执行的呢?CPU又是如何执行的呢?今天跟随小编的脚步去化解开这个疑惑❓。 在学习这个过程之前,我们需要先讲解一些与本内容相关的知识点 指令 指令是指导CPU运行的命令,主要由操作码+被操作数组成。 其中操作码用来表示要做什么动作,被操作数是本条指令要操作的数据,可能是内存地址,也