细!首席技术官在线优化Kubernetes上的JVM预热问题

本文介绍了在Kubernetes上运行Java服务时遇到的JVM预热问题及其解决方法。通过增加应用数量、使用预热脚本、调整启发式技术和配置Burstable QoS类,最终成功减少了预热期间的响应时间和错误,实现了平稳部署和自动伸缩。
摘要由CSDN通过智能技术生成

前言

JVM 预热(warm-up)是一个臭名昭著的问题。尽管基于JVM的应用程序有着出色的性能,但是需要一个预热的过程,在预热期间,性能不是最佳的。它可以归因于即时(JIT)编译之类的事情,它通过收集使用情况配置文件信息来优化常用代码。最终的负面影响是,与平均时间相比,在预热期间收到的请求将具有非常高的响应时间。在容器化,高吞吐量,频繁部署和自动伸缩的环境中,此问题可能会加剧。

在这篇文章中,我将讨论我们在Kubernetes集群中使用Java服务关于JVM预热问题的经验和方法。

创世记

几年前,我们从单体架构逐步转为微服务架构,并且部署到Kubernetes中。大多数新服务都是用Java开发的。当我们启用Java服务时,我们首先遇到了这个问题。通过负载测试执行了正常的容量规划过程,并确定N个容器足以处理超出预期的峰值流量。

尽管该服务可以毫不费力地处理高峰流量,但我们开始在部署过程中发现问题。我们的每个Pod在高峰时间处理的RPM都超过10k,而我们使用的是Kubernetes滚动更新机制。在部署期间,服务的响应时间会激增几分钟,然后再稳定到通常的稳定状态。在我们的NewRelic仪表板中,我们将看到类似于以下的图形:

细!首席技术官在线优化Kubernetes上的JVM预热问题

 

同时,依赖于我们该部署的其他服务在相关时间段内也发生了高响应时间和超时错误。

Take 1: 增加应用数目

我们很快意识到该问题与JVM预热阶段有关࿰

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值