作者:哎呦我去2502859031 | 来源:互联网 | 2023-08-28 10:02
一. 调优需要关注的几个方面
内存调优
CPU 使用调优
锁竞争调优
I/O 调优
二. Twitter 最大的敌人:延迟
导致延迟的几个原因?
三. 内存性能调优
(1)内存占用调优
OutOfMemoryError 异常原因:可能真的数据量太大、可能要数据显示的太多、可能内存泄露
数据量太大观察及解决:
数据臃肿(Fat data)
数据臃肿原因:
(1)对象头(JVM 对象头一般占用两个机器码,在 32-bit JVM 上占用 64bit, 在 64-bit JVM 上占用 128bit 即 16 bytes, 例如:new java.lang.Object() 占用 16 bytes; new byte[0] 占用 24 bytes) 更多对象头内容参考:http://blog.csdn.net/wenniuwuren/article/details/50939410
(2)填充补全
看个例子
new D() 占用 24 bytes 空间, new E() 占用 32 bytes 空间。 具体空间计算参考:http://blog.csdn.net/wenniuwuren/article/details/50958892
现在一般是 64-bit 的 JVM,64-bit 的指针会导致 CPU 缓存相比 32-bit 指针减少很多, 所以建议 JVM 参数加入 -XX:+UseCompressedOops 采用指针压缩将 64-bit 指针压缩为 32-bit, 但是却又能使用 64-bit 的内存空间, 达到一举两得的作用。另外,建议最大堆小于 30G。
尽量别使用原始类型对象的包装类
在 Scala 2.7.7 中:Seq[Int] 存 Integer,Array[Int] 存 int, 第一个空间占用 (24 + 32*length) bytes,第二个空间占用 (24 + 4*length) bytes。
在 Scala 2.8 中修复了这个问题, 从这我们可以看出:
Map 空间占用(Map footprints)
小心使用 Thread Local
典型的问题在线程池 m*n 的资源相关,如 200 线程池使用了 50 个连接,最终有 10000 个连接缓存
考虑使用同步对象或者每次新建一个对象
四. 与延迟做斗争
性能三角
图2:压缩(Compactness,即减小内存占用)率上升,吐量上升,响应速度上升
新生代是如何工作的?
所有新对象分配在 Eden 代,因为新生代 GC 有压缩,所以内存分配用指针碰撞
当 Eden 满的时候,进行一次 stop-the-world 的 Minor GC,存活下来的放到 Survivor
经过几次 Minor GC,还存活下来的对象会被提升(tenured)到老年代
理想化得新生代操作
Eden 代足够容纳超过一组并发的请求和响应对象(这样没有 stop-the-world,吞吐量会比较高)
每个 Survivor 空间足够容纳活跃对象和有年龄的对象(减少过早提升到老年代)
提升阈值正好能让存活时间长的对象早点提升到老年代(给 Survivor 腾出空间)
从新生代开始调优
(1)-XX:+PrintHeapAtGC
(2)-XX:+PrintTenuringDistribution
CMS 调优
响应速度还是太慢?
Minor GC 时有太多存活对象,尝试减少新生代空间,减少 Survivor 空间,减少晋升阈值
太多线程。尝试找到最小的并发层次或者增加更多 JVM 实例
尝试使用 Volatile 而不是 synchronized 减少锁竞争,尝试使用 Atomic* 的原子类
用分配 slab 应对 CMS 的碎片问题
Apache 的 Cassandra 内部使用 slab 分配。每个 slab 大小为 2MB,使用 CAS 复制 byte[] 到里面,使用 Cassandra 前开销为 30-60 秒每小时, 使用后在3天零十小时开销 5 秒。
使用分配 slab 的方式有一些局限性:在缓存满的时候才把缓存内容写进磁盘,而且对象需要转化为二进制等问题。