内容字号:默认大号超大号

段落设置:段首缩进取消段首缩进

字体设置:切换到微软雅黑切换到宋体

中间件_sql更新数据库_学生机

2021-07-23 01:59 出处:欧普曼云计算 人气: 评论(0

中间件_sql更新数据库_学生机

在撰写本文时(2020年3月),您可以将600多个参数传递给JVM,这些参数只涉及垃圾收集和内存。如果您包括其他方面,那么JVM参数总数将很容易超过1000+这对于任何人来说都是太多的参数了。在本文中,我们将重点介绍七个重要的JVM参数,您可能会发现它们很有用。

-Xmx可能是最重要的JVM参数。-Xmx定义了分配给应用程序的最大堆大小。(要了解JVM中的不同内存区域,您可以观看这个简短的视频剪辑)。你可以这样定义你的应用程序的堆大小:

堆大小在决定你的

a.应用程序性能

b.账单,你将从你的云提供商(AWS,Azure,…)那里得到

这带来了一个问题,我的应用程序的合适堆大小是多少?我应该为我的应用程序分配大的堆大小还是小的堆大小?答案是:'这取决于'。在这篇文章中,我们分享了我们的想法,你是否需要使用大堆大小还是小堆大小。

元空间是JVM元数据定义(如类定义、方法定义)的存储区域。默认情况下,可用于存储此元数据信息的内存量是无限的(即受容器或计算机的RAM大小限制)。您需要使用-XX:MaxMetaspaceSize参数来指定可用于存储元数据信息的内存量上限。

截止日期(2020年3月),OpenJDK中有7种不同的GC算法:

a.串行GC

b.并行GC

c.并发标记扫描GC

d.G1 GC

e.Shenandoah GC

f.Z GC

g.Epsilon GC

如果没有明确指定GC算法,那么JVM将选择默认算法。在Java8之前,并行GC是默认的GC算法。由于Java 9,G1 GC是默认的GC算法。

GC算法的选择对决定应用程序的性能起着至关重要的作用。基于我们的研究,我们观察到Z-GC算法具有良好的性能。如果您使用的是jvm11+,那么可以考虑使用zgc算法(即-XX:+UseZGC)。有关Z GC算法的更多详细信息可在此处找到。

下表总结了激活每种类型的垃圾收集算法需要传递的JVM参数。

垃圾收集日志包含有关垃圾收集事件、回收内存、暂停持续时间、,…您可以通过传递以下JVM参数来启用垃圾收集日志:

从JDK 1到JDK 8:

从JDK 9及更高版本:

示例:

通常GC日志用于调整垃圾收集性能。然而,GC日志包含重要的微观指标。这些指标可用于预测应用程序的可用性和性能特征。在本文中,我们将重点介绍一个这样的微观度量:"GC吞吐量"(要阅读更多关于其他可用微观度量的内容,请参阅本文)。GC吞吐量是应用程序处理客户事务所花费的时间与处理GC活动所花费的时间之比。假设应用程序的GC吞吐量为98%,则表示应用程序将98%的时间用于处理客户活动,剩下的2%用于GC活动。

现在让我们看看健康JVM的堆使用率图:

图:健康JVM的堆使用率图(由https://gceasy.io)

你可以看到一个完美的锯齿图案。您可以注意到,当Full GC(红色三角形)运行时,内存利用率会一直下降到底部https://gceasy.io)

您可以注意到,在图的右端,即使GC重复运行,内存利用率没有下降。这是一个典型的迹象,表明应用程序正遭受某种内存问题的困扰。

如果您仔细查看该图,您将注意到重复的完整GC在上午8点左右开始发生。但是,应用程序仅在上午8:45左右才开始出现OutOfMemoryError。到上午8点,应用程序的GC吞吐量约为99%。但就在上午8点之后,GC吞吐量开始下降到60%。因为当重复GC运行时,应用程序不会处理任何客户事务,它只会执行GC活动。作为一种主动措施,如果您注意到GC吞吐量开始下降,您可以从负载平衡器池中取出JVM。这样不健康的JVM就不会处理任何新的流量。它将最大限度地减少对客户的影响。

图:在OutOfMemoryError之前重复执行完全GC

您可以使用GCeasy REST API实时监控GC相关的微测量。

OutOfMemoryError是一个严重的问题,会影响您的应用程序的可用性/性能SLA。要诊断OutOfMemoryError或任何与内存相关的问题,必须在应用程序开始出现OutOfMemoryError之前的某一时刻或几分钟捕获堆转储。由于我们不知道何时抛出OutOfMemoryError,因此很难在抛出堆转储时在正确的时间手动捕获堆转储。但是,通过传递以下JVM参数可以自动捕获堆转储:

-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath={heap-DUMP-FILE-PATH}

在'-XX:HeapDumpPath'中,您需要指定堆转储应该存储的文件路径。当您传递这两个JVM参数时,好的云服务器,当抛出OutOfMemoryError时,堆转储将被自动捕获并写入定义的文件路径。示例:

一旦捕获到堆转储,您可以使用诸如HeapHero、EclipseMAT之类的工具来分析堆转储。

关于OutOfMemoryError JVM参数的更多详细信息可以在本文中找到。

每个应用程序将有数十、数百、数千个线程。每个线程都有自己的堆栈。在每个线程的堆栈中存储以下信息:

a.当前执行的方法/函数

b.基本数据类型

c.变量

d.对象指针

e.返回值。

每个都消耗内存。如果它们的消耗量超过某个限制,则抛出stackoverflowerr。关于stackoverflowerr及其解决方案的更多细节可以在本文中找到。但是,可以通过传递-Xss参数来增加线程的堆栈大小限制。例如:

如果您将这个-Xss值设置为一个巨大的数字,那么内存将被阻塞和浪费。假设您将-Xss值指定为2mb,而它只需要256kb,那么您将浪费大量内存,淘客返利软件,而不仅仅是1792kb(即2mb–256kb)。你想知道为什么吗?

假设您的应用程序有500个线程,那么-Xss值为2mb时,您的线程将消耗1000mb内存(即500个线程x 2mb/线程)。另一方面,如果您只将-Xss分配为256kb,那么您的线程将只消耗125mb内存(即500个线程x 256kb/线程)。每个JVM将节省875mb(即1000mb–125mb)内存。是的,物联网水表,它将产生如此巨大的差异。

注意:线程是在堆外创建的(即-Xmx),因此这1000mb将是您已经分配的-Xmx值的补充。为了理解为什么线程是在堆外创建的,你可以看这个视频短片。

我们建议从一个较低的值(比如256kb)开始。使用此设置运行彻底的回归、性能和AB测试。只有在遇到StackOverflowerError时才增加值,否则请考虑使用较低的值。

现代应用程序使用多种协议(即SOAP、REST、HTTP、HTTPS、JDBC、RMI…)来连接远程应用程序。有时远程应用程序可能需要很长时间才能响应。有时它可能根本没有响应。

如果你没有正确的超时设置,如果远程应用程序响应不够快,那么你的应用程序线程/资源就会卡住。远程应用程序无响应可能会影响应用程序的可用性。它可以使你的应用程序停止运行。为了保护应用程序的高可用性,应该配置适当的超时设置。

您可以在JVM级别传递这两个强大的超时网络属性,这两个属性可以全局适用于所有使用的协议处理程序java.net.url连接:

例如,如果您想将这些属性设置为2秒:

注意,这两个属性的默认值是-1,这意味着没有设置超时。更多关于这些属性的细节可以在本文中找到。-双时区

分享给小伙伴们:
本文标签: 中间件更新数据库生机

相关文章

评论

发表评论愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。

签名: 验证码: 点击我更换图片

评论列表