攀枝花仁和住房和城乡建设局网站,网站建设费用分类,wordpress开奖,清溪镇网站仿做最近#xff0c;笔者的技术群里有人问了一个有趣的技术话题#xff1a;单核CPU, 1G内存的超低配机器#xff0c;怎么做JVM调优#xff1f;这实际上是两个问题。单核CPU的超低配机器#xff0c;怎么充分利用CPU#xff1f;单核CPU, 1G内存的超低配机器#xff0c;怎么做J…最近笔者的技术群里有人问了一个有趣的技术话题单核CPU, 1G内存的超低配机器怎么做JVM调优这实际上是两个问题。单核CPU的超低配机器怎么充分利用CPU单核CPU, 1G内存的超低配机器怎么做JVM调优怎么充分利用CPU这个问题不能一概而论要结合具体场景。对于IO密集型和CPU密集型的应用调优的方法会截然不同。IO密集型有频繁外部设备访问的应用如磁盘访问和网络访问等。由于CPU性能相对硬盘读写和网络访问要好很多系统执行任务时大部分的情况是CPU在等I/O (磁盘/网络) 的读/写操作在发生I/O操作时cpu处于等待状态这就可能导致cpu的利用率不高。CPU密集型: 以计算为主很少有磁盘和网络访问的应用。这种任务CPU一直在运行CPU的利用率很高。在给出CPU调优结论之前先花两分钟熟悉一下I/O基础。所谓的I/OInput/Output操作实际上就是输入输出的数据传输行为。程序员最关注的主要是磁盘IO和网络IO因为这两个IO操作和应用程序的关系最直接最紧密。磁盘IO磁盘的输入输出比如磁盘和内存之间的数据传输。网络IO不同系统间跨网络的数据传输比如两个系统间的远程接口调用。下面这张图展示了应用程序中发生IO的具体场景通过上图我们可以了解到IO操作发生的具体场景。一个请求过程可能会发生很多次的IO操作1页面请求到服务器会发生网络IO2服务之间远程调用会发生网络IO3应用程序访问数据库会发生网络IO4数据库查询或者写入数据会发生磁盘IO下面是执行top命令查看CPU状况的截图从上图我们可以看到:CPU空闲率是0%上图中红框idCPU使用率是22%上图中红框 us 13% 加上 sy 9%us可以理解成用户进程占用的CPUsy可以理解成系统进程占用的CPUCPU 在等待磁盘IO操作上花费的时间占比是76.6% 上图中红框 wa不少人会这样理解如果CPU空闲率是0%就代表CPU已经在满负荷工作没精力再处理其他任务了。真是这样的吗我们先看一下计算机是怎么管理磁盘IO操作的。计算机发展早期磁盘和内存的数据传输是由CPU控制的也就是说从磁盘读取数据到内存中是需要CPU存储和转发的期间CPU一直会被占用。我们知道磁盘的读写速度远远比不上CPU的运转速度。这样在传输数据时就会占用大量CPU资源造成CPU资源严重浪费。后来有人设计了一个IO控制器专门控制磁盘IO。当发生磁盘和内存间的数据传输前CPU会给IO控制器发送指令让IO控制器负责数据传输操作数据传输完IO控制器再通知CPU。因此从磁盘读取数据到内存的过程就不再需要CPU参与了CPU可以空出来处理其他事情大大提高了CPU利用率。这个IO控制器就是“DMA”即直接内存访问Direct Memory Access。现在的计算机基本都采用这种DMA模式进行数据传输。通过上面内容我们了解到IO数据传输时是不占用CPU的。当应用进程或线程发生IO等待时CPU会及时释放相应的时间片资源并把时间片分配给其他进程或线程使用从而使CPU资源得到充分利用。所以假如CPU大部分消耗在IO等待wa上时即便CPU空闲率id是0%也并不意味着CPU资源完全耗尽了如果有新的任务来了CPU仍然有精力执行任务。如下图在DMA模式下执行IO操作是不占用CPU的所以CPU IO等待上图的wa实际上属于CPU空闲率的一部分。所以我们执行top命令时除了要关注CPU空闲率CPU使用率ussy还要关注IO Waitwa。注意wa只代表磁盘IO Wait不包括网络IO Wait。了解完IO的基础知识我们看看在单核CPU的超低配机器上怎么充分利用CPU对于IO密集型应用。CPU会有很多时间花在IO等待上发生IO时虽然CPU空闲率上图的id受到影响但是实际上cpu并没有干活。这时就需要较多的线程数量当一部分线程因为IO问题被阻塞时其他空闲线程还能继续接收并执行其他请求任务。这样cpu利用率就会更高。同时还要考虑线程间上下文切换带来的性能开销线程数量不能太高。对于单核CPU要根据IO的密集程度设置线程数。由于CPU只有一核资源有限所以除了对线程数的优化外主要还是要优化IO操作减少IO操作频率缩短IO操作时间。IO操作优化之后线程数可以设置成更少线程切的换频率和性能开销也会随之降低。对于CPU密集型应用。线程数应该尽可能少一些在没有任何IO操作的情况下为了减少线程切换带来的性能开销理论上最佳的线程数量应该设置成CPU的核数。不过实际场景中绝大多数应用或多或少都会有一定的IO操作比如记录Log访问数据库或者跨网络的远程调用等这样线程数就需要适当调大。至于设置成多少就没有定论了需要我们多次调整验证取性能测试的最优结果。对于单核CPU为了减少线程切换带来的性能开销一两个线程基本就够了。怎么做JVM调优选择合适的垃圾收集器CMS和G1是目前最炙手可热的两个垃圾回收器基本上所有公司都在使用CMS或G1。不过在单核CPU内存只有1G的机器上CMS和G1就不太合适了。以CMS回收过程为例在耗时较长的并发标记和并发清除阶段垃圾收集线程和用户线程是同时并行工作的也就是说并发阶段不会导致用户线程停顿。不过CMS对CPU资源非常敏感。 其实所有高并发的应用对CPU资源都很敏感。在CMS并发阶段并发标记和并发清除阶段虽然不会导致用户线程停顿但是垃圾收集线程会占用一部分CPU资源进而导致应用程序变慢吞吐量降低。CMS默认启动的垃圾收集线程数是CPU核数3/4当CPU核数在4个以上时并发回收阶段垃圾收集线程不少于25%的CPU资源CPU核数。但是当CPU核数不足4个时比如CPU核数为2个CMS对用户程序的影响就可能变得很大此时需要分配1个核的资源去执行垃圾收集任务如果本来CPU负载就比较大还要分出一半的计算能力去执行垃圾收集任务就可能导致应用程序的执行速度大幅下降甚至忽然降低50%以上着实让人无法接受。在单核CPU环境下并发标记和并发清除阶段是无法真正做到并发的当垃圾收集线程执行标记和清除任务时单核CPU唯一的核就无法执行用户线程这样就会造成严重的用户线程阻塞问题导致应用程序响应超慢。说到这有人可能会问换成其他垃圾收集器在单核CPU环境下不一样会有这种因为线程阻塞导致的应用程序执行变慢的问题吗没错换成其他垃圾收集器在单核CPU环境下一样会有同样的问题。不过情况应该会比使用CMS或者G1要好CMS是响应速度优先的老年代垃圾收集器是一种以降低GC全局停顿时间Stop The World为目标的收集器。为了实现这一目标CMS把垃圾回收分成了初始标记并发标记重新标记和并发清除4个阶段。其中初始标记和重新标记两个阶段会停止所有用户线程发生STW不过耗时很短。并发标记和并发清除两个阶段耗时最长但是这两个阶段垃圾收集线程可以和用户线程一起工作不会停止用户线程。CMS的这种设计虽然缩短了STW的时间但是整个GC过程四个阶段加在一起的总时间更长了。如果在单核CPU环境下并发标记和并发清除两个阶段就无法做到真正的并发因为单核的问题垃圾收集线程和用户线程不可能同时占用唯一的CPU资源所以在垃圾收集线程运行时所有用户线程都会被停止相当于发生了STW。基本上可以这样理解在单核CPU环境下CMS的四个阶段都会发生Stop The World。也就是说在单核CPU环境下CMS的Stop The World时间比传统的老年代收集器Serial Old和Parallel Old还要长。所以在单核CPU环境下绝对不能选择CMS和G1这种对CPU特别敏感的收集器。考虑到Parallel Old是一款多线程并发收集器主要为了利用多核CPU来提高垃圾回收效率不适合单核环境。所以基本上最古老的Serial Old收集器就成了单核CPU的最佳选择啦。另外1G的内存空间太小也不适合CMS和G1。数年前在CMS和G1还没诞生之前很多互联网系统使用Serial Old和Parallel Old做为老年代收集器这样会带来一个严重问题堆内存越大垃圾回收时STWStop The World时间就越长在互联网系统中堆内存往往会超过4G每次Full GC时STW时间会很长可能会达到几秒钟甚至更长也就是说JVM在这几秒钟内无法处理任何用户请求。这在高并发的互联网系统中是无法接受的。后来随着CMS和G1先后应运而生解决了较大堆内存GC时STW时间过长的问题。所以说CMS和G1只是为了大内存场景设计的不适合小内存场景在小内存场景下不能发挥自己的优势。如果内存只有1G单核CPU下为了提高吞吐量可以选择Serial Old。多核CPU下为了充分发挥多核作用提高垃圾收集效率可以选择多线程并发收集器Parallel Old。降低GC频次在给出具体降低GC频次方案之前我们以Java官方的HotSpot JVM为例先了解一下堆内存分布以及对象的分配和流转过程。JVM将堆内存分为了三部分新生代Young Generation老年代Old Generation永久代Permanent Generation。其中新生代又分为三部分伊甸园区Eden和两个幸存区S0和S1。注JDK1.8之后Java官方的HotSpot JVM去掉了永久代取而代之的是元数据区Metaspace。Metaspace使用的是本地内存而不是堆内存也就是说在默认情况下Metaspace的大小只与本地内存的大小有关。因此JDK1.8之后就见不到java.lang.OutOfMemoryError: PermGen space这种由于永久代空间不足导致的内存溢出的问题了。堆内存中对象的分配和流转过程新创建的对象会先被分配到到Eden区。JVM刚启动时Eden区对象数量较少两个Survivor区S0、S1几乎是空的。随着时间的推移Eden区的对象越来越多。当Eden区放不下时占用空间达到容量阈值新生代就会发生垃圾回收我们称之为Minor GC或者Young GC。发生GC时第一步会通过可达性分析算法找到可达对象。如上图蓝色为可达对象其他紫色为不可达对象。第二步被标示的可达对象会被转移到S0此时S0是From Survivor此时存活对象年龄加1三个对象年龄都变为1。第三步清除Eden区所有对象。GC后各区域对象占用情况如上图所示。程序继续运行Eden区再次达到容量阈值时会再次发生GC。这时S0From Survivor已经有了对象。还是同样的步骤通过可达性分析算法找到可达对象然后再将Eden和S0中的可达对象转移到S1To Survivor各存活对象年龄加1。最后将Eden和S0中的所有对象清除。GC后S0区域被清空。如上图所示。S0和S1发生了互换S1变成了From SurvivorS0变成了To Survivor。注意To Survivor区永远都为空。这实际上是垃圾回收算法-复制算法在年轻代的实际应用。把年轻代分为EdenS0S1三个区域每次垃圾回收时把可达对象复制到S0或S1然后再清除掉Eden和S1或S0中的所有对象。由于每次GC时新生代的可达对象非常少绝大部分对象要被回收掉一般不会超过新生代总体空间的10%所以搜寻可达对象以及复制对象的成本都会非常低。而且这种复制的方式还能避免产生堆内存碎片提高内存利用率。很多年轻代垃圾收集器都采用复制算法如ParNew。在程序运行过程中新生代GC会反复发生长寿对象会在S0和S1之间反复交换年龄也会越来越大当对象达到年龄上限时会被晋升到老年代。这个年龄上限默认是15可以通过参数-XX:MaxTenuringThreshold设置。如下图有些年轻代对象年龄达到了上限15被转移到了老年代。通过上面的图文内容我们了解了堆内存中对象的分配和流转过程。那么可以基于这些知识来做一些JVM调优的工作。所谓降低GC频次主要指的是降低Major GC老年代GC次数。内存只有1G为了减少Major GC最简单的做法是适当调大老年代比例但是老年代空间总有个上限需要在老年代和年轻代之间找一个平衡点。还可以适当调大MaxTenuringThreshold来提高年轻代幸存区s0和s1的交换次数进而减少对象晋升到老年代的几率。另外调大幸存区比例也可以减少基于动态对象年龄判定导致对象晋升老年代的几率。不管是哪种优化手段都需要反复调整和验证可以做性能测试验证调整结果。再补充一个基础知识点。Full GCMajor GCMinor GC之间是什么关系当前绝大部分垃圾收集器都采用分代回收的策略年轻代和老年代的GC分别独立进行。一般情况下老年代Major GC是由年轻代Minor GC触发的Minor GC会导致部分存活时间较长的对象晋升到老年代在晋升过程中如果老年代使用空间达到阈值就会发生Major GC。这种由Minor GC触发Major GC引发整个堆内存GC的情况我们一般称之为Full GC。还有一些情况也会触发Major GC比如大对象初始化时会跨过年轻代直接分配到老年代这种情况触发的Major GC和Minor GC就没半点关系了。可以通过-XX:PretenureSizeThreshold参数设置大对象的大小如果参数被设置成5MB超过5MB的大对象会直接分配到老年代。缩短GC时间缩短GC时间和降低GC频次两者是鱼和熊掌的关系不可兼得。如上面所说在1G内存单核CPU的场景下响应时间优先的CMS和G1都不适合。在垃圾收集器没有太多选择的情况下如果想缩短Major GC时间基本上只能减小老年代的比例了老年代空间越小每次Major GC需要处理的对象就越少GC时间也就越短。老年代空间越小GC的频次自然也会更高内存空间就那么多所以我们需要反复试验在GC频次和GC时间上找到最佳平衡点来满足业务系统的要求。结语JVM调优没有什么可以拿来即用的固定模板或规范每个应用都有自己的独特场景。不同的应用并发程度不一样对响应时间和吞吐量要求也不一样堆内存对象规模、对象生命周期、对象大小等等都不会完全一样这些因素都会影响到JVM的性能。所以JVM调优是一个循序渐进的过程必然需要经历多次迭代最终才能得到一个较好的折中方案。
