flink 集群容器化建设及利用率提升 flink 容器化 针对于流计算 flink 集群的云原生渗透力提升，我们在今年上半年开始了 flink 集群容器化建设，该操作目前已实现 Barad 小地域全覆盖这些地域的整体架构实现了...ps: 替换资源选择建议 16CU 的小核心机器。原因是每个节点固定会有两个 CU 被预留给 TKE 的管控信息通信。大于 16CU 可能就不灵活，而 8CU 的话 CU 实际工作的占比又太低。...同一个机器下的作业，可以调度到分配之外的CPU(只要没有被使用的话)。这就会引入一个现象:EMR 集群下性能弹性空间会更大，CPU 利用率可以超过 100%。...而实际集群使用中，由于历史遗留和资源不足原因，我们用一些 CPU 内存不是1:4 标准配置的节点来搭建集群，比如 16U32G。...对这种情况，各个地域缩容后的节点可以单独再起一个集群，平时低负载运行一些小型作业，需要补算时，会临时拿来进行离线补算。 此外，将大型作业，动辄 300CU 以上的作业，单独搭建集群运行。
原因分析： 在排查问题时，发现有问题的服务器上，CPU利用率非常高，达到197%，内存的使用率也非常高，几乎已经没有剩余空间。那么，这是由什么原因引起的呢？...熟悉Docker都知道，Docker容器中使用的资源是固定的，包括磁盘空间、CPU以及内存等，不能超过容器在初始时分配的大小。那么，Docker是如何实现这个功能的呢？...背压（Back Pressure）是流控制中的一种策略，主要用于保护系统在高负载情况下的稳定性。...Flink任务会被分解为子任务，子任务会被分配到不同的机器上执行。如果某些高耗CPU或者高耗IO的任务集中在同一台机器，会导致该机器的处理能力不足，从而影响整个任务的处理速度。...当系统经过几年的发展，可能会变得杂乱无章，各个系统之间的联系混乱不堪。在这样的情况下，可能对系统的运行逻辑一头雾水，更别说从这个混乱的拓扑中找出问题所在。
Oceanus对正在运行的作业采集了大量的指标，通过这些指标来监控作业运行情况，并在发生故障时定位原因。...当一个作业中出现这样的task时，我们就需要通过性能优化或者增加并发度的方式来提高这个task的处理性能。 输入和输出的TPS也是在作业运行中的关键指标。...当一个task的最大和最小TPS之间出现较大的差值时，一般就意味着作业中出现了负载倾斜。负载倾斜会对作业的性能造成较大的影响，同时也很难通过增加并发度的方式来提高性能。...当我们增加更多的aggregator时，因为绝大部分word仍然只会被发送到少数那几个aggregator上，程序性能也不会得到任何提高。...由于在一定时间段内发送给下游的数据量不过超过上游的并发度，下游的负载倾斜可以有效缓解。同时由于数据在上游一般没有较为严重的倾斜，程序性能不会由于负载倾斜而严重降低。
该集群有十来个业务接口访问，每个接口部署在数十台业务服务器上面，访问该MongoDB机器的客户端总数超过数百台，部分请求一次拉取数十行甚至百余行数据。...2.2.1 机器系统监控分析 机器CPU和系统负载监控如下： ? 从上图可以看出，几乎和前面的突发流量引起的系统负载过高现象一致，业务CPU sy%负载100%，load很高。...2.3 线下模拟故障 到这里，我们已经大概确定了问题原因，但是为什么故障突发时间点那一瞬间2万个请求就会引起sy%负载100%呢，理论上一秒钟几万个链接不会引起如此严重的问题，毕竟我们机器有40个CPU...Linux-3.10，并发20000反复建链断链的时候，sy%负载可以达到30%，随着客户端并发增加，sy%负载也相应的增加。...答：频繁建链断链的根本原因是系统sy%负载高，客户端极短时间内建立链接后又端口的原因是客户端配置超时时间太短。
作者 | Lasse Vilhelmsen 译者 | 刘雅梦 策划 | 李冬梅 文描述了一个自动化的 CPU 垂直扩展系统的实现，在该系统中，优步（Uber）上运行的每个存储工作负载都被分配到了理想数目的内核...通过设定目标，比如 40% 的 CPU 利用率，可以相当肯定的是，在区域故障转移期间，CPU 利用率不会超过 80%，在最坏的情况下，负载会短暂地增加一倍。...选择 40% 是为了确保有空间进行区域故障转移（可能会使负载增加一倍）。之所以选择 40%，是因为我们不想超过大约 80% 的 CPU 利用率。...从图 3 也可以清楚地看出，高类别容器的比例有所上升。这实际上是有意为之的，因为我们已经意识到，在区域故障转移期间，一些存储集群的负载不会增加太多。...8 小时时间间隔的 P99 确保 CPU 利用率在每 8 小时的窗口中最多有 5 分钟超过这个值。我们已经尝试了从 4 小时到 24 小时的不同采样窗口。
1）分析 分析调用链路，找到慢的地方对其进行优化，提升服务端的响应速度。 如下图所示，很明显可以看到服务端执行时间超过了客户端配置的超时时间 200ms 导致超时。...如下面两张图，流量正常的情况下 HTTP 线程数增加，说明是服务端响应变慢导致，可以确认超时是服务端原因。 图7 服务流量平稳 图8 HTTP线程数突增 b....3.8 优化 JIT JIT（Just-In-Time）编译可以提高程序的运行效率，灰度接入流量将字节码编译成本地机器码，避免对接口性能的影响。...JIT 会在程序运行时，将频繁执行的代码块编译为本地机器码，然后再执行机器码，这样可以大大提高程序的执行效率。 2）分析 JIT 技术可以根据程序的实际运行情况，动态地优化代码，使得程序的性能更好。...图22 服务拉入后请求量和响应时间 3.9 换宿主机 当宿主机负载过高时，可以考虑更换宿主机，避免宿主机负载过高影响容器负载。 1）分析 a.
Flink Forward 以前只在美国和德国举办，2018年12月20日首次来到中国。腾讯云大数据团队参加了会议并在会上介绍团队在公有云流计算平台服务化过程中的一些监控运维经验。...基础监控系统 [njss5z59rk.png] 这是一个比较简单的事后监控告警系统，Flink 作业通过 PerJob 模式在 Yarn 上运行，支撑服务周期性检查 Yarn Application...以及 Flink Job 的状态，当发现异常时发送告警。...展望规划 在运维监控方面，SCS 的中短期计划主要有3个；首先是完善 Metrics 指标系统，包括增加 Metric 辅助问题定位以及优化 Flink 原生 Metric 实现，同时在监控系统中增加对各种...Metrics 的深度分析，加入更多的机器学习算法预测潜在的问题，打造更加智能化的监控系统；其次是提供自动化的在线弹性伸缩能力，实时跟踪预测业务负载，自动进行在线低延时动态扩缩容；最后是完善作业日志的实时收集和分析
磁盘带宽，如果您依赖于基于磁盘的状态后端，如 RocksDB（并考虑其他磁 盘使用，如 Kafka 或 HDFS） 可用的机器数量、CPU 和内存 Flink CheckPoint问题如何排查？...，当集群资源接近用满时（例如 90% 以上），可能存在资源碎片的情况，应用的分配速度就会受影响变慢，因为大部分机器都没有资源了，机器可用资源不足会被 reserve，reserved 资源达到一定规模后可能导致大部分机器资源被锁定...该异常在 Flink AM 向 YARN NM 申请启动 token 已超时的 Container 时抛出，通常原因是 Flink AM 从 YARN RM 收到这个 Container 很久之后（超过了...意思说是机器上的系统时间可能不同步。同步集群机器时间即可。...当一个正常运行的作业失败时，日志里会有 from RUNNING to FAILED 的关键字，我们以此为着手点，查看它后面的 Exception 原因，通常最下面的 caused by 即是直接原因。
问题描述 给 24个 TaskManager(CPU) 都会出现来不及消费的情况 问题原因 做窗口聚合的任务的分组字段，分组粒度太小，hash不能打散，数据倾斜严重，导致少数 TaskManager 上压力过大...指标正常，但是没处理到数据 问题原因 Topic中单条数据 > 1M，超过 Kafka Consumer 处理单条数据的默认最大值。...:142) 程序内存占用过大，导致TaskManager在yarn上kill了，分析原因应该是资源不够，可以将程序放在资源更大的集群上，再不行就设置减少Slot中共享的task的个数，也可能是内存泄露或内存资源配置不合理造成...检查一下当前YARN集群的状态、正在运行的YARN App以及Flink作业所处的队列，释放一些资源或者加入新的资源。...意思说是机器上的系统时间可能不同步。同步集群机器时间即可。
问题描述： Flink各项metrics指标正常，但是没处理到数据。 问题原因： Topic中单条数据> 1M，超过Kafka Consumer处理单条数据的默认最大值。...，导致TaskManager在yarn上kill了，分析原因应该是资源不够，可以将程序放在资源更大的集群上，再不行就设置减少Slot中共享的task的个数，也可能是内存泄露或内存资源配置不合理造成，需要进行合理分配...检查一下当前YARN集群的状态、正在运行的YARN App以及Flink作业所处的队列，释放一些资源或者加入新的资源。...设置的太小了，默认是10min，这里只设置了8sec。当一个Flink App背压的时候（例如由外部组件异常引起），Barrier会流动的非常缓慢，导致Checkpoint时长飙升。...意思说是机器上的系统时间可能不同步。同步集群机器时间即可。
问题现象 近期我们发现 Kubernetes 环境下的 Flink 集群有个奇怪的现象：在算子并行度较大（例如超过 50）时，Flink 的 TaskManager 注册异常缓慢（具体表现为 TaskManager...Stopping the JobMaster for job" slot.request.timeout: 500000 # 增加单次尝试的最大超时时间 cluster.registration.max-timeout...处理流程阻塞，异步部分迟迟得不到执行，TaskManager 与 JobManager 之间的一问一答变成了只问不答（消息超过超时时间被丢弃）。...点此查看 Flink 文档中关于如何参与贡献的说明。 邮件讨论 当遇到疑难问题时，建议订阅并向 Flink 的 User 组发邮件进行咨询。...后来我们找到问题根源后，社区的 Till 也建议我来进行问题的修复。为了反馈问题，发现者可以在 Flink 的 JIRA 上提个单，提单前需要先注册账号。
；系统资源消耗上，我们基于数据尽可能不丢的运营思路，即使同样采用单副本存储模式，TubeMQ使用的资源也可以比其他的MQ低50%左右的机器资源；同时，系统基于SAAS而非PAAS实践思路设计，在系统管控上要比其他...： 机器配置 过滤份数 生产 消费 入流量 出流量 64G内存，2核共24个逻辑CPU 50份 103395/s 141776/s 1.078Gb/s 1.37Gb/s 256G内存，2核共96个逻辑CPU...并且支持同一个库中行存列存表混合，隔离OLTP负载与OLAP负载等技术。在易用性方面，相比GP的长时间的停机扩容，TBase能够做到高速且在线的扩容，对业务的影响降到最小。...而当用户需要修改程序并发度时，Flink也可以自动地将状态数据分发到新的计算节点上。 Flink提供了丰富的容错语义。...、互联网保险、理赔等全链条业务系统，保险业务复杂，需要多表关联查询，tbase功能丰富，复杂SQL运算性能更好，目前运行实例超过200+；公安涉及业务人口库业务、人口轨迹大数据等业务系统，目前应用规模超过
一般情况下对于机器性能，load、cpu、mem是越低越好，如果有一个超过了既定指标都代表着可能出现了问题，就需要尽快解决（当然有可能是应用的问题也有可能是机器上其他程序引起的），反正就是如果不解决，时间长了肯定不好.../网络/锁） Tn： 线程数 Tno：最佳线程数 Cn：cpu核数 Cu：cpu使用率 注：以下的讨论均限于机器负载小于平均负载的情况，机器负载太高的时候，以下的公式并不适用。...在一般的服务器上，程序运行的瓶颈资源有可能是cpu、也可以是内存、锁、IO等，他们都可以影响到程序运行的时间，体现在公式上就是Tic和Tiw，分表代表程序执行的cpu运行时间和程序等待资源的时间。...在线程数没有达到最佳线程数之前，增加线程可以提高qps，同时rt不变（增加不大）；当线程数超过了最近线程则qps不会在提高，而rt则会变大。...应用的负荷真的很大，当所有优化手段都做了，还是无法降下来，可以考虑加机器，不丢人。 对于load偏高的原因，不仅仅只是有应用自身引起的，机器上其他程序也有可能导致机器整体的load偏高。
因此，HPA不扩展，Pod的数量为1 超过这一点，处理工作负载所需的总CPU使用量将增加80%以上 HPA扩大部署，增加一个副本，因此运行的pod总数= 2 现在，有两个pod在运行，累积CPU负载为~...工作负载在一段时间内保持较低的水平，CPU使用率< 20% 然后突然出现高峰，CPU使用率>在短短几秒内达到80% 预期是，当CPU使用率超过80%时，HPA应该启动一个新的pod来处理增加的工作负载...30秒)提供聚合指标，在这30秒间隔内的聚合平均CPU利用率为21%——远低于80%的目标 由于这些原因，即使在一个pod中出现了工作负载峰值，导致该pod上的> CPU使用量达到80%，HPA也不会通过扩展更多副本来做出响应...如果一个新的副本不能从流量中分得一杯羹，那么扩展它还有什么意义呢? 当HPA发出一个scale请求时，Kubernetes控制平面将新的pod调度到一个适当的工作节点上运行。...这有以下副作用: 硬件资源很贵，比平时贵100倍 所有这些钱都花在了机器人流量上，并没有增加任何商业价值 它将集群置于胁迫之下。
Kafka在美团的集群规模总体机器数已经超过了15000+台，单集群的最大机器数也已经到了2000+台。在数据规模上，天级消息量已经超过了30+P，天级消息量峰值也达到了4+亿/秒。...造成慢节点的原因有三个： 集群负载不均衡会导致局部热点，就是整个集群的磁盘空间很充裕或者ioutil很低，但部分磁盘即将写满或者ioutil打满。...IO密集型应用在这里指的就是Kafka，CPU密集型应用在这里指的是Flink和Storm。...通过新的隔离策略，Kafka的读写延时不再受Flink CPU飙升的影响。...但是实际上，PageCache的容量往往是不足的，因为它不会超过一个机器的内存。容量不足时，ZeroCopy就会触发磁盘读，磁盘读不仅显著变慢，还会污染PageCache影响其他读写。
MR/SPARK/Flink实现了自己的AM逻辑在yarn上运行。 1.1 参考文章 主要是参考下面两篇文章，个人觉得有代表性，可以管中窥豹。下面对此两篇文章的内容一律以引用格式。...对于流式的实时数据处理需求，我们上层有一个青藤平台来托管FLINK在YARN上运行。...非受控 Container 的清理机制 由于种种原因，线上总是会出现一些 Container 明明还在运行，但是已经不受 YARN 的管控。...，多少 GB 内存，但在训练场景下，有时希望有范围，比如当需要两个 GPU 卡时，不止希望随意的两张卡，而是希望要一台机器上两个连号的 GPU 卡，比如卡 0 和卡 1 是连号的，而卡 0 和卡 2 不是连号的...3.1 物理利用率提升 yarn现在主要托管的是一些离线计算的资源，公司还有很多空闲资源没有使用，怎么来使用这些空闲资源，怎么做到把一些合适的任务调入到一些比较空闲的机器上，当这个机器需要的时候，
我们在各种类型的流处理应用程序上对Flink性能进行测试，并通过在Apache Storm（一种广泛使用的低延迟流处理器）上运行相同的实验来进行对比。 1....当启用记录确认机制（保证At-Least-Once语义）时，Storm的吞吐量降至每核每秒4700个元素，延迟也增加到30-120毫秒。...我们在30台机器的集群中运行此作业，其系统配置与以前相同。Flink实现了每核每秒大约720,000个事件的吞吐量，启动检查点后降至690,000。...出现延迟增加的原因是需要对齐流，算子等待接收所有输入的 ‘barrier’。Storm具有非常低的中位数延迟（1毫秒），并且第99百分位的延迟也是51毫秒。...相应的吞吐量为每个核每秒24,500个事件。当我们增加缓冲区超时时间时，我们会看到延迟增加，吞吐量会同时增加，直到达到吞吐量峰值，缓冲区填充速度超过超时到期时间。
如低版本的客户端写入高版本的kafka时，如果使用数据压缩，则服务端接受到数据后，会解压，然后再按照对应的格式压缩（如果版本一致，则不会有此动作），增加服务端的运行成本。...，像日志采集的后端应用，需要负责日志的采集和解析，尤其像解析日志会很耗cpu的，这样数据量一大很容易碰天花板 Heka 12000 对比logstash，其处理数据过程，对机器性能消耗较少，‘体重较轻’...四、上云之后的变化 ES/KAFKA上云之后，统计有50多个ES集群，12个Kafka集群. 1....工作量的减少 如果不上云的话，搭建这些集群平均一个ES集群需要20台机器，从申请机器，到机器初始化，磁盘RAID，安装ES，平均一个ES需要3-4人/天，则搭建成本就已经需要200多人(62*3-4)/...1.核心模块既要有日志，也要有监控，不同模块的监控维度对应起来，让核心的模块，日志和监控都有，当业务出现异常时，及时调出发生异常的基础数据（如CPU/Mem等），指标数据，日志数据等进行完整的监控体系的建设
，一旦超过这个值，客户端就启动自适应限流机制，新产生的请求在本地会被概率（以下称为p）丢弃； 当客户端主动丢弃请求时，requests 值会一直增大，在某个时间点会超过 K∗accepts，使 p 计算出来的值大于...独立扩展 通过 CQRS 模式，读服务和写服务可以独立地进行扩展； 如果系统的读负载较高，可以增加读服务的实例数量；如果写负载较高，可以增加写服务的实例数量。...3.2.3 核心隔离 核心隔离通常是指将资源按照 “核心业务”与 “非核心业务”进行划分，优先保障“核心业务”的稳定运行AI助手 核心/非核心故障域的差异隔离（机器资源、依赖资源）； 核心业务可以搭建多集群通过冗余资源来提升吞吐和容灾能力...使用方法 EMA 动态超时根据业务的请求链路有两种用法： 1.用于非关键路径 Thwm 设置的相对小，当非关键路径频繁耗时增加甚至超时时，降低超时时间，减少非关键路径异常带来的资源消耗，提升服务吞吐量。...当 CPU 使用率超过 80% 时，根据 MaxPass 和 MinRt 计算窗口内理论上可以通过的最大请求量，进而确定每秒的最大请求数。如果当前处理中的请求数超过此计算值，则进行请求丢弃。
GB以内的小状态或者无Keyed State，这些任务TaskManager所运行的机器整体利用率明显偏低，如果所在机器没有大State存在，当前机器的高性能大磁盘存在较为明显的浪费。...Flink流计算的Checkpoint机制是其可靠性的基石，当一个任务在运行过程中出现故障时，可以根据Checkpoint的信息恢复到故障之前的某一状态，然后从该状态恢复任务的运行，而Checkpoint...在做功能测试时，发现一个任务在同等资源情况下，使用TaishanStateBackend的CPU负载更高，经过诊断发现当State的rpc请求量越大时，网络消耗CPU占比越大。...我们内部的Flink BSQL任务目前对State均有24小时的默认TTL设置，当State的数据超过24小时未访问后，State会失效过期，并随后在RocksDB做compaction时被移除，这样的配置也基本上能满足大多数用户的实际使用的...未来我们计划参考Flink Forward Asia 2022中提到的Tiered State Backend的思路，将机器上的磁盘和内存都作为缓存加速的资源，同时保持状态数据完整保存在远程存储上，形成一套分层状态存储的架构
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
云直播
对象存储
腾讯会议
