深入理解JVM系统性能优化

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

从服务本身来看，影响服务性能的主要包扣：

  • 我们写代码时所选择的数据结构和算法

  • 服务开启的线程时是否合理

  • WEB应用，WEB服务

  • JVM方面的影响

  • 最后是操作系统的影响

从整个服务架构上来看还有：

  • 数据持久化

  • 服务间的远程调用

  • 消息缓存等中间件的选择

常用的性能测试指标

响应时间

一个请求从提交到响应所耗费的时间，一般比较关注平均响应时间，和最大响应时间。

常用组件的响应时间：

操作|响应时间

---|---

打开一个站点 |几秒

数据库查询一条记录（有索引）| 十几毫秒

机械磁盘一次寻址定位| 4毫秒

从机械磁盘顺序读取1M数据 |2毫秒

从SSD磁盘顺序读取1M数据| 0.3毫秒

从远程分布式缓存Redis读取一个数据|0.5毫秒

从内存读取1M数据 |十几微妙

Java程序本地方法调用 |几微妙

网络传输2Kb数据 |1微妙

从上述表格我们能看出：

  1. 数据持久化，使用SSD与使用机械硬盘相比性能可以提高将近10倍；

  2. 数据查询，数据如果直接在本地内存，那么它的读取效率比数据库快将近1000倍，比redis快30倍左右；如果数据在redis缓存，那么它的读取速度比数据库快30倍左右；这也是为什么使用缓存是提升系统性能的“银弹”的原因。

为监控而生的多级缓存框架 layering-cache这是我开源的一个多级缓存框架的实现，如果有兴趣可以看一下。

并发数

并发数是指同一时刻，对服务器有实际交互的请求数。一般并发数是在在线用户数的5%-15%之间，如在线用户数是1000，那么可以预估并发数在50-150之间。

吞吐量

吞吐量是单位时间内完成的工作量(请求)的数量。如：每分钟的数据库事务，每秒传送的文件千字节数，每分钟的 Web 服务器命中数。

关系

通常，平均响应时间越短，系统吞吐量越大；平均响应时间越长，系统吞吐量越小。但是，系统吞吐量越大， 未必平均响应时间越短。

性能优化原则

避免过早优化

不应该把大量的时间耗费在小的性能改进上，过早考虑优化是所有噩梦的根源。在开发初期我们的首要目标是完成功能，编写清晰，直接，易懂的代码。

进行系统性能测试

所有调优都应该建立在新能测试的基础上，不要满目靠猜测进行优化。

寻找系统瓶颈，分而治之，逐步优化

性能测试后，对整个请求经历的各个环节进行分析，排查出现性能瓶颈的地方，定位问题，分析影响性能的的主要因素是什么？内存、磁盘IO、网络、CPU，还是代码问题？架构设计不足？或者确实是系统资源不足？

常用的性能优化手段

前端优化常用手段

浏览器/App

  1. 减少请求数

    合并CSS，Js，图片；

  2. 使用客户端缓存；

    静态资源文件缓存在浏览器中，如果文件发生了变化，则通过改变文件名来更新缓存。

  3. 启用压缩

    它可以减少网络传输量，但会给浏览器和服务器带来性能的压力，需要权衡使用。

  4. 资源文件加载顺序

    css放在页面最上面，js放在最下面。

  5. 减少Cookie传输

    cookie会包含在每次的请求和响应中，因此哪些数据写入cookie需要慎重考虑。

CDN加速

CDN，又称内容分发网络，本质仍然是一个缓存，而且是将数据缓存在用户最近的地方。免费的CDN加速器七牛云。

反向代理缓存

将静态资源文件缓存在反向代理服务器上，一般是Nginx。

WEB组件分离

浏览器在同一个域名下下载资源存在并发限制，所以，将js，css和图片文件放在不同的域名下，可以提高浏览器在下载web组件的并发数。

应用服务性能优化

缓存

缓存的本质是将数据存放在访问速度较高的介质中，可以减少数据访问的时间，同时避免重复计算。

从上面响应时间表格我们可以看出，使用缓存将数据缓存在本地或者redis服务器，将会对查询效率有较大的提升。网站性能优化的第一定律也是使用缓存，为监控而生的多级缓存框架 layering-cache这是我开源的一个多级缓存框架的实现，如果有兴趣可以看一下。

集群

负载均衡服务器（nginx，f5等）使用负责均衡算法，将请求分发到多个节点上进行处理。

异步

同步和异步关注的是结果消息的通信机制：

  • 同步：同步的意思就是调用方需要主动等待结果的返回；

  • 异步：异步的意思就是不需要主动等待结果的返回，而是通过其他手段比如，状态通知，回调函数等；

阻塞和非阻塞主要关注的是等待结果返回调用方的状态：

  • 阻塞：是指结果返回之前，当前线程被挂起，不做任何事；

  • 非阻塞：是指结果在返回之前，线程可以做一些其他事，不会被挂起；

BIO、NIO和AIO

  • 同步阻塞：去商店买衣服，你去了之后发现衣服卖完了，商家说要去库房拿，那你就在店里面一直等，期间不做任何事(包括看手机)，等着商家拿货，这就是同步阻塞，效率低；

  • 同步非阻塞：去商店买衣服，你去了之后发现衣服卖完了，商家说要去库房拿，这时你可以去继续逛街，但是时不时需要回去问商家货到了没，这就是同步非阻塞；

  • 异步阻塞：去商店买衣服，你去了之后发现衣服卖完了，这个时候时候你给商家留下电话，等货到了电话通知你，然后你就啥事都不敢，守着电话等通知，这个模式有点傻，用的很少；

  • 异步非阻塞：去商店买衣服，你去了之后发现衣服卖完了，这时候你给商家留下电话，然后就可以去逛街了，等货物到了商家会回电话通知你。

jdk里的BIO就属于同步阻塞；jdk里的NIO就属于同步非阻塞；jdk里的AIO就属于异步。

常见的异步组件

  • Servlet3

  • 多线程

  • 消息队列

代码级别

  1. 选择合适的数据结构，比如ArrayList和LinkedList的适用场景；

  2. 选择更优的算法，比如最大子序列和问题，选择穷举算法那么时间复杂度是O(n^3)；如果选择动态规划算法，那么时间复杂度就是O(n)了；

  3. 编写更精简的代码，同样正确的程序，小程序比大程序要快；

  4. 并发编程，充分利用多核CPU资源；

  5. 同步情况下减少锁的竞争；

  6. 资源的复用，比如单例模式，池化技术；

  7. 序列化优化，比如redis的使用默认的JDK序列化和FastJson序列化，最后JDK序列化所暂用的空间是FastJson的3倍左右；

GC优化

GC优化的终极目的

  • GC的时间够小

  • GC的次数够少，发生Full GC的周期足够的长，时间合理，最好是不发生。

GC运行指标

如果满足则一般不需要调优：

  • Minor GC执行时间不到50ms；

    - Minor GC执行不频繁，约10秒一次；

  • Full GC执行时间不到1s；

  • Full GC执行频率不算频繁，不低于10分钟1次；

调优的原则

  1. 大多数的java应用不需要GC调优

  2. 大部分需要GC调优的的，不是参数问题，是代码问题

  3. 在实际使用中，分析GC情况优化代码比优化GC参数要多得多；

  4. GC调优是最后的手段

GC调优的最重要的三个选项

  1. 选择合适的GC回收器

  2. 选择合适的堆大小

  3. 选择年轻代在堆中的比重

GC调优的步骤

  1. 监控GC的状态

    使用各种JVM工具，查看当前日志，分析当前JVM参数设置，并且分析当前堆内存快照和gc日志，根据实际的各区域内存划分和GC执行时间，觉得是否进行优化；

  2. 分析结果，判断是否需要优化

    如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化；如果GC时间超过1-3秒，或者频繁GC，则必须优化；

  3. 调整GC类型和内存分配

    如果内存分配过大或过小，或者采用的GC收集器比较慢，则应该优先调整这些参数，并且先找1台或几台机器进行beta，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择；

  4. 不断的分析和调整

    通过不断的试验和试错，分析并找到最合适的参数

  5. 全面应用参数

    如果找到了最合适的参数，则将这些参数应用到所有服务器，并进行后续跟踪。

GC日志

以参数-Xms5m -Xmx5m -XX:+PrintGCDetails -XX:+UseSerialGC为例：

[DefNew: 1855K->1855K(1856K), 0.0000148 secs][Tenured: 2815K->4095K(4096K), 0.0134819 secs] 4671K

  • DefNew：指明了收集器类型，而且说明了收集发生在新生代。

  • 1855K->1855K(1856K)：表示，回收前 新生代占用1855K，回收后占用1855K，新生代大小1856K。

  • 0.0000148 secs： 表明新生代回收耗时。

  • Tenured：表明收集发生在老年代

  • 2815K->4095K(4096K)：回收前后的值

  • 0.0134819 secs：老年代回收耗时

  • 最后的4671K指明堆的大小。

收集器参数变为-XX:+UseParNewGC，日志变为：

[ParNew: 1856K->1856K(1856K), 0.0000107 secs][Tenured: 2890K->4095K(4096K), 0.0121148 secs]

收集器参数变为-XX:+ UseParallelGC或UseParallelOldGC，日志变为：

 [PSYoungGen: 1024K->1022K(1536K)] [ParOldGen: 3783K->3782K(4096K)] 4807K->4804K(5632K)

CMS收集器和G1收集器会有明显的相关字样

GC相关的参数

  • -verbose:gc和 -XX:+PrintGC：打印简单的GC日志

  • -XX:+PrintGCDetails和 +XX:+PrintGCTimeStamps：打印详细的GC日志

  • -Xlogger:[logpath]：指定GC日志路径，如Xlogger:log/gc.log

  • -XX:+PrintHeapAtGC：打印推信息，获取Heap在每次垃圾回收前后的使用状况

  • -XX:+TraceClassLoading： 在系统控制台信息中看到class加载的过程和具体的class信息，可用以分析类的加载顺序以及是否可进行精简操作。

  • -XX:+DisableExplicitGC：禁止在运行期显式地调用System.gc()

  • -XX:-HeapDumpOnOutOfMemoryError：默认关闭，建议开启，在java.lang.OutOfMemoryError 异常出现时，输出一个dump.core文件，记录当时的堆内存快照。

  • -XX:HeapDumpPath=./java_pid<pid>.hprof：默认是java进程启动位置，用来设置堆内存快照的存储文件路径。

存储性能优化

  • 尽量使用SSD；

  • 定时清理数据或者按数据的性质分开存放；

  • 结果集处理，如：用setFetchSize控制jdbc每次从数据库中返回多少数据；

以上是 深入理解JVM系统性能优化 的全部内容， 来源链接： utcz.com/z/514117.html

回到顶部