精华内容
下载资源
问答
  • 订单的秒杀模块jvm调优案例 1. jvm调优思路         jvm调优其实更多的是对GC的优化,尤其是尽量减少full GC。         大多数...


    1. jvm调优思路

            jvm调优其实更多的是对GC的优化,尤其是尽量减少full GC。

            大多数情况下,对象在Eden区分配,当Eden区没有足够空间进行分配时,虚拟机将进行一次Minor GC ,可能有99%的对象被标记为垃圾被回收,剩余存活的对象会进入为空的survivor,下一次Eden区满了之后,又会触发minor gc,把Eden区和survivor区垃圾对象回收,把剩余存活的对象一次性挪动到另外一块为空的to区,因为新生代的对象都是朝生夕死的,存活时间很短,所以JVM默认的8:1:1的比例是很合适的,让eden区尽量的大,survivor区够用即可。

    • Minor GC/Young GC:指发生新生代的的垃圾收集动作,Minor GC非常频繁,回收速度一般也比较快。
    • Major GC/Full GC:一般会回收老年代 ,年轻代,方法区的垃圾,Major GC的速度一般会比Minor GC的慢 10倍以上。
    • Eden与Survivor区默认8:1:1

    明白了上边的对象流转过程,我们可以在这个过程中做一些手脚,来进行jvm调优!


    1.1 jvm调优方案

    • ①:设置大对象直接进入老年代! 大对象就是需要大量内存空间的对象(比如数组、字符串) ,通过jvm参数-XX:PretenureSizeThreshold 可以设置大对象的大小,如果对象超过设置大小会直接进入老年代,不会进入年轻代,这个参数只在 Serial 和ParNew两个收集器下有效。
      • 具体操作:-XX:PretenureSizeThreshold=1000000 (单位是字节) -XX:+UseSerialGC
      • 使用场景:当我们可以确定系统中的对象大部分为大对象,且短期内不会被垃圾回收,就可以根据对象大小设置jvm参数,让这些大对象直接进入老年代,省去了对象在新生代流转的过程,节省了Eden区的空间,因为大对象最终总会进入老年代的,还不如提前让出Eden空间,让他处理更多的小对象,提升系统性能!
    • ②:设置长期存活的对象提前进入老年代! 新生代的对象每熬过一次Minor GC ,其年龄就会+1,默认15岁,也就是流转15次就会进入老年代。当我们的系统中大概有大部分(80%)的对象都会经过15次Minor GC 进入老年代,我们可以通过设置-XX:MaxTenuringThreshold来调整进入老年代需要的年龄阈值。比如设置年龄为8即可进入老年代,这样那些长期存活的对象,就可以尽早的进入老年代,减少对象在新生代的流转次数,提升了系统性能!
    • ③:根据survivor区的动态年龄判断机制,合理设置新生代大小 。一般超过survivor区大小的60%会发生动态年龄判断机制,此时把最老的对象放进老年代。可以适当增加survivor区的大小避免Full GC!动态年龄判断的机制作用其实是希望那些可能是长期存活的对象,尽早进入老年代,避免多次复制操作而降低效率。


    2. 订单的秒杀模块jvm调优案例

    架构如下:

    对亿级电商平台的调优中,首先要对自己的系统有足够的了解。根据以上架构:

    • ①:如果平台日活用户为500w,那大部分的付费转化率为10%,也就是每日50w单左右。
    • ②:如果50w单是在平时非促销的时候,下订单操作通过负载均衡打到服务器上,也就每秒几单、十几单的样子,服务器可以抗住。但如果要搞促销,50w单要在几分钟内产生,那么每秒钟就高达1000多单的交易,如果不合理设置jvm参数,就可能会频繁发生Full GC!
    • ③:假设有订单三台服务器,每秒1000单通过负载均衡到三台服务器,每台服务器每秒处理300单左右!每个订单对象的大小是由order类中的字段来决定的,假设每个订单对象有几十个字段,撑死1kb,每秒300kb对象生成,订单接口中肯定不止一个订单对象,还有库存、优惠券、积分等对象,所以300kb放大20倍,也就是6MB,同时还可能有别的操作,比如订单查询等,再放大10倍,也就是60MB,因为要保证请求速度,所以这60MB对象1s后都会成为垃圾。
    • ④:此时每秒60M对象进入堆内存。假如服务器内存是8G,给操作系统分配4-5G,剩下的分给JVM,因为 新生代:老年代 = 1:2,则新生代拿到1G,老年代2G,元空间512Mb,栈1M,jvm参数设置 如图所示!对象会首先进入Eden,800/60 ≈ 14秒 ,也即14秒时Eden区被放满,发生Minor GC!

    在这里插入图片描述

    • ⑤:Minor GC会进行stw,前13秒的对象直接被gc掉。然而由于gc时的stw,用户线程无法执行,此时可能第14秒创建的对象会没有使用完,就会一直被引用着,GC完毕后,第14秒创建的对象由于被引用而存活了下来,此时存活的对象会进入survivor区。由于survivor区存在动态年龄判断机制:如果Survivor区中的这批对象总大小大于Survivor区域内存大小的50%,那么>=这批年龄最大值的对象,都会被放入老年代。 该组对象大小>50MB,年龄都是1,所以此时第14秒这批对象都会直接进入老年代。也就是每14秒60M对象进入老年代!导致几分钟一次GC!
    • ⑥:由于上述原因就是由survivor区存在动态年龄判断机制导致的,所以我们可以通过调整新生代大小来避免,对象进入老年代!
      在这里插入图片描述
      把年轻代分配2G,则survivor区为200M,60M的对象进来不至于触发动态年龄判断机制,一次Minor GC就杀死了所有对象,几乎没有对象进入老年代,解决了Fulle GC频繁的问题!

    结论:通过上面这些内容介绍,大家应该对JVM优化有些概念了。

    • 尽可能让对象都在新生代里分配和回收,尽量别让太多对象频繁进入老年代,避免频繁对老年代进行垃圾回收。
    • 同时给系统充足的内存大小,避免新生代频繁的进行垃圾回收。
    展开全文
  • jvm调优案例

    千次阅读 2019-09-05 11:34:15
    JVM调优 JVM 收集器 默认使用串行收集器, 单个cpu时适用吞吐收集器(throughput collector):命令行参数:-XX:+UseParallelGC。在新生代使用并行清除收集策略,在旧生代和默认收集器相同。 适用:a、拥有2个以上...

    JVM调优

    JVM 收集器

    默认使用串行收集器, 单个cpu时适用吞吐收集器(throughput collector):命令行参数:-XX:+UseParallelGC。在新生代使用并行清除收集策略,在旧生代和默认收集器相同。
    适用:a、拥有2个以上cpu, b、临时对象较多的程序
    -XX:ParallelGCThreads 并行收集线程数量,最好和cpu数量相当并发收集器(concurrent low pause collector):命令行参数:-XX:+UseConcMarkSweepGC。在旧生代使用并发收集策略,大部分收集工作都是和应用并发进行的,在进行收集的时候,应用的暂停时间很短。默认配套打开 -XX:+UseParNewGC,会在新生代使用并行复制收集。
    适用:a、拥有多个cpu, b、老对象较多的程序

    -XX:+UseCMSCompactAtFullCollection:打开对年老代的压缩。可能会影响性能,但是可以消除碎片  
    -XX:+UseFastAccessorMethods 原始类型的快速优化  
    -XX:SurvivorRatio 新生区中,eden&survivor的比例,设置为8  
    -XX:TargetSurvivorRatio 生存区需要做垃圾回收的比例值,默认为50%,设置高些可以更好的利用该区

     

    设置jvm参数

    $ java -jar -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -Xms1024m -Xmx1024m -Xmn256m -Xss256k -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC newframe-1.0.0.jar

     

    $JAVA_ARGS  
    .=  
    "  
    -Dresin.home=$SERVER_ROOT  
    -server  
    -Xmx3000M  
    -Xms3000M  
    -Xmn600M  
    -XX:PermSize=500M  
    -XX:MaxPermSize=500M  
    -Xss256K  
    -XX:+DisableExplicitGC  
    -XX:SurvivorRatio=1  
    -XX:+UseConcMarkSweepGC  
    -XX:+UseParNewGC  
    -XX:+CMSParallelRemarkEnabled  
    -XX:+UseCMSCompactAtFullCollection  
    -XX:CMSFullGCsBeforeCompaction=0  
    -XX:+CMSClassUnloadingEnabled  
    -XX:LargePageSizeInBytes=128M  
    -XX:+UseFastAccessorMethods  
    -XX:+UseCMSInitiatingOccupancyOnly  
    -XX:CMSInitiatingOccupancyFraction=70  
    -XX:SoftRefLRUPolicyMSPerMB=0  
    -XX:+PrintClassHistogram  
    -XX:+PrintGCDetails  
    -XX:+PrintGCTimeStamps  
    -XX:+PrintHeapAtGC  
    -Xloggc:log/gc.log  
    ";

     

    调优策略

    JVM各个参数之间有一个平衡性的,另外根据业务类型和实际的运行环境都有不一样的效果。但是有些约定俗成的规定还是值得借鉴的:  
    1)堆内存不超过物理内存的3/4   
    2)年轻代的大小不超过堆内存的3/8   
    3)CMSInitiatingOccupancyFraction一般不低于70%

    (Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2))
     

    参考参数:

    xms xmn survivor xmn gc
    6G 6G 4 2G CMSInitiatingOccupancyFraction=70
    6G 6G 3 1.75G CMSInitiatingOccupancyFraction=70

    工具使用

    查看线程cpu占用1

    [root@localhost ~]# ps p 6515 -L -o pcpu,pid,tid,time,tname,cmd --sort pcpu  
    %CPU   PID   TID     TIME TTY      CMD  
     0.0  6515  6515 00:00:00 pts/1    java -jar xxl-job-admin-2.0.2-SNAPSHOT.jar  
     0.0  6515  6523 00:00:04 pts/1    java -jar xxl-job-admin-2.0.2-SNAPSHOT.jar  
     0.0  6515  6529 00:00:00 pts/1    java -jar xxl-job-admin-2.0.2-SNAPSHOT.jar

     

    查看线程cpu占用2

    [root@localhost ~]# ps -mp 6515 -o THREAD,tid,time  
    USER     %CPU PRI SCNT WCHAN  USER SYSTEM   TID     TIME  
    root      0.3   -    - -         -      -     - 00:00:58  
    root      0.0  19    - futex_    -      -  6515 00:00:00  
    root      0.0  19    - futex_    -      -  6523 00:00:04  
    root      0.0  19    - futex_    -      -  6529 00:00:00  
    root      0.0  19    - futex_    -      -  6530 00:00:00

     

    找到的线程ID转换为16进制格式

    [root@localhost ~]# printf "%x\n" 6523  
    197b

     

    打印线程的堆栈信息

    [root@localhost ~]# jstack 6515 | grep 197b -A 30  
    "DestroyJavaVM" #94 prio=5 os_prio=0 tid=0x00007f83f004b000 nid=0x197b waiting on condition [0x0000000000000000]  
       java.lang.Thread.State: RUNNABLE
    
    "http-nio-9988-AsyncTimeout" #92 daemon prio=5 os_prio=0 tid=0x00007f83f0758000 nid=0x19e4 waiting on condition [0x00007f8352bee000]  
       java.lang.Thread.State: TIMED_WAITING (sleeping)  
        at java.lang.Thread.sleep(Native Method)  
        at org.apache.coyote.AbstractProtocol$AsyncTimeout.run(AbstractProtocol.java:1149)  
        at java.lang.Thread.run(Thread.java:748)
    
    "http-nio-9988-Acceptor-0" #91 daemon prio=5 os_prio=0 tid=0x00007f83f0382800 nid=0x19e3 runnable [0x00007f8352cef000]  
       java.lang.Thread.State: RUNNABLE  
        at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)  
        at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)  
        at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)  
        - locked <0x00000006c7c2ada0> (a java.lang.Object)  
        at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:482)  
        at java.lang.Thread.run(Thread.java:748)
    
    "http-nio-9988-ClientPoller-1" #90 daemon prio=5 os_prio=0 tid=0x00007f83f11d1000 nid=0x19e2 runnable [0x00007f8352df0000]  
       java.lang.Thread.State: RUNNABLE  
        at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)  
        at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)  
        at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)  
        at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)  
        - locked <0x00000006c7c2b548> (a sun.nio.ch.Util$3)  
        - locked <0x00000006c7c2b538> (a java.util.Collections$UnmodifiableSet)  
        - locked <0x00000006c7c2b400> (a sun.nio.ch.EPollSelectorImpl)  
        at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)  
        at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:825)  
        at java.lang.Thread.run(Thread.java:748)

     

    执行jmap把当前的堆dump下来

    jmap -dump:live,format=b,file=dump.hprof 6515

     

    将dump.hprof文件使用VisualVM来打开

     

    SpringBoot TOMCAT调优

    tomcat参数说明

    maxThreads 客户请求最大线程数   
    minSpareThreads Tomcat初始化时创建的 socket 线程数   
    maxSpareThreads Tomcat连接器的最大空闲 socket 线程数   
    enableLookups 若设为true, 则支持域名解析,可把 ip 地址解析为主机名   
    redirectPort 在需要基于安全通道的场合,把客户请求转发到基于SSL 的 redirectPort 端口   
    acceptAccount 监听端口队列最大数,满了之后客户请求会被拒绝(不能小于maxSpareThreads )   
    connectionTimeout 连接超时   
    minProcessors 服务器创建时的最小处理线程数   
    maxProcessors 服务器同时最大处理线程数   
    URIEncoding URL统一编码

     

    tomcat在springboot上的配置ServerProperties.java --> application.properties

    server.tomcat.accesslog.enabled =  
    server.tomcat.accesslog.pattern =  
    server.tomcat.accesslog.directory =  
    server.tomcat.accesslog.prefix =  
    server.tomcat.accesslog.suffix =  
    server.tomcat.accesslog.rotate =  
    server.tomcat.accesslog.renameOnRotate =  
    server.tomcat.accesslog.requestAttributesEnabled=  
    server.tomcat.accesslog.buffered =  
    server.tomcat.internalProxies =  
    server.tomcat.protocolHeader =  
    server.tomcat.protocolHeaderHttpsValue =  
    server.tomcat.portHeader =  
    server.tomcat.remoteIpHeader=  
    server.tomcat.basedir =  
    server.tomcat.backgroundProcessorDelay =  
    server.tomcat.maxThreads =  
    server.tomcat.minSpareThreads =  
    server.tomcat.maxHttpPostSize =  
    server.tomcat.maxHttpHeaderSize =  
    server.tomcat.redirectContextRoot =  
    server.tomcat.uriEncoding =  
    server.tomcat.maxConnections =  
    server.tomcat.acceptCount =  
    server.tomcat.additionalTldSkipPatterns =

     

    tomcat在application.yml上的配置

    server:  
      tomcat:  
        min-spare-threads: 20  
        max-threads: 100  
      connection-timeout: 5000

     

    参考:
    1.JAVAEE文档:https://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
    2.深入理解JAVA虚拟机(内存模型+GC算法+JVM调优):https://www.cnblogs.com/yueshutong/p/9768298.html
    3.JVM调优实践:https://blog.wangqi.love/articles/Java/JVM%E8%B0%83%E4%BC%98%E5%AE%9E%E8%B7%B5.html
    4.JVM解读-性能调优实例:https://www.jianshu.com/p/2c4b091deaa3
    5.扩容?先尝试一下JVM调优吧:https://sq.163yun.com/blog/article/211688346067283968
    6.JVM调优参数简介、调优目标及调优经验https://blog.csdn.net/jisuanjiguoba/article/details/80176223
    7.jvm优化必知系列——监控工具https://juejin.im/post/59e6c1f26fb9a0451c397a8c
    8.JVM活学活用——优化springboothttps://cloud.tencent.com/developer/article/1089954
    9.SpringBoot服务器压测对比(jetty、tomcat、undertow)https://my.oschina.net/shyloveliyi/blog/2980868

    展开全文
  • JVM实战-JVM调优案例分析与MyEclipse性能调优实战
  • JVM调优案例

    2019-06-26 15:35:57
    一、常见虚拟机配置参数汇总 堆配置 -Xms4g:初始堆大小 -Xmx4g:最大堆大小 ...如:为3,表示年轻代与年老代比值为1:...jmap -dump:fomart=b,file=dump.bin pid dump jvm内存快照,使用mat工具进行离线分析  

    一、常见虚拟机配置参数汇总

    堆配置

    -Xms4g:初始堆大小
    -Xmx4g:最大堆大小
    -Xmn2g :年轻代大小 
    -Xss1024K:线程栈大小
    -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4
    -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:3,表示Eden:Survivor=3:2,一个Survivor区占整个年轻代的1/5
    -XX:MaxPermSize=n:设置持久代大小

    垃圾收集器配置

    -XX:+UseSerialGC:设置串行收集器
    -XX:+UseParallelGC:设置并行收集器
    -XX:+UseParalledlOldGC:设置并行年老代收集器
    -XX:+UseConcMarkSweepGC:设置并发收集器

    垃圾回收统计信息配置

    -XX:+PrintGC
    -XX:+PrintGCDetails
    -XX:+PrintGCTimeStamps
    -Xloggc:filename

     

    二、调优步骤

    ps -ef|grep 查看线程pid

    jstat -gcutil pid 1000 查看gc情况

    jmap -histo pid > jmap.txt 使用jmap分析对象占用内存情况

    jmap -dump:fomart=b,file=dump.bin pid  dump jvm内存快照,使用mat工具进行离线分析

     

    展开全文
  • JVM实践(三)JVM调优案例 大部分的JVM调优,目的是降低GC次数,减少GC时间(STW耗时占大部分)。 从原因分析上 FULL GC频率高。正常10天半个月可能FULL GC一次,如果一天两三次就不正常了。 可能的原因: (1...

    JVM实践(三)JVM调优案例

    大部分的JVM调优,目的是降低GC次数,减少GC时间(STW耗时占大部分)。

    从原因分析上

    FULL GC频率高。正常10天半个月可能FULL GC一次,如果一天两三次就不正常了。

    可能的原因:

       (1)内存泄漏,属于代码问题。

    首先分析大对象,找到它,修复它,可能是代码上的缺陷,又或者是程序设计上漏洞。

       (2)元空间(metaspace,Java8后才有,以前是“永久代”)超了。项目代码量很大,类的基本信息(或者说静态数据)撑爆了元空间,触发了GC。

    java -XX:+PrintFlagsInitial|grep MetaspaceSize 查看元空间初始值

    修改默认值16m--->32m

    -XX:MetaspaceSize=32m

    具体案例分析

         其实到现在,是不是觉得还是手足无措,第一次吃饭,不知道怎么吃,不知道饭是怎么到肚子里的。不知道用碗盛饭,不知道用筷子夹菜,不知道用勺子舀汤。想知道怎么做吗? 别问我,我也不知道,睡觉去。

    案例1:我可以想象一下,假设你系统运行很慢——堆内存不足

    首先,登录linux服务器,输入命令jps,找到java的进程号。

    然后,看一下性能情况,也就是GC情况,输入命令:jstat -gc  -t  [进程号] 1s 5

    1).有可能你看到了GC次数多次。

    那么,你可以看下堆内存分配情况:jmap -heap [进程号]

    如果最大堆内存很小,就调大一下比如:512m-->4096m。

    案例2:系统启动很慢——元空间不足

    同样,jstat分析一下FULL GC情况,如果发现,唉,在启动的时候居然还FULL GC了一两次,那一般就是你的元空间不足啦。

    -XX:MetaspaceSize=32m        16m-->32m

    案例3:同样系统运行慢——代码内存泄漏

    开头已经说过了,找到可能出现在老年代的大对象,这种啃老族应该找出来消灭它。那怎么操作呢?

    首先,必须的两步肯定是 看进程号,看jstat。确认FULL GC次数多,然后再用jmap查看堆内存分配,那这种情况肯定是老年代存活了很多大对象了。看下图中那个used使用量,如果大于0肯定是存活着对象了。

    接着,分析堆内存。有两种方式可以跟踪:

    1.实时:jmap -dump:format=b,file=e:\a\heap.hprof [进程号]  实时查看jvm内存信息。

    2.溢出跟踪:jvm启动参数中添加  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=e:\a\java.hprof

    此方法可以在内存溢出的时候dump出.hprof文件。可以下载到windows本地,然后在JDK的bin目录下,文件名就叫jvisualvm.exe点击运行,选择hprof文件,就可以分析了。

    最后,分析到原因了,就改bug吧。

     

    展开全文
  • jvm调优案例分析与实战 一. 高性能硬件上的调优: 1. 采用64位操作系统,并为JVM分配大内存 我们知道,如果JVM中堆内存太小,那么就会频繁地发生垃圾回收,而垃圾回收都会伴随不同程度的程序停顿,因此,如果扩大堆...
  • JVM调优案例问题 问题 我们公司的程序是的B/S架构,工作中碰到客户提出一个问题,他们的系统最近突然会用着用着就卡死掉–浏览器访问服务器一开始会卡顿,直至最终会完全卡死没有响应。 并且客户反馈的是最近才变卡...
  • JVM调优案例分析

    2020-12-25 16:26:50
    这是笔者很久之前处理过的一个案例,但今天仍然具有代表性。一个15万PV/日左右的在线文档类型网站最近更换了硬件系统,服务器的硬件为四路志强处理器、16GB物理内存,操作系统为64位 CentOS 5.4,Resin作为Web服务器...
  • 记一次线上生产JVM调优过程。 一. 线上问题,no BB,看图 应用堆内存使用情况如下图: 应用youngGC如下图: 这里没有给出fullGC的图片,基本上每一小时一次fullGC。 正常应用堆内存使用情况如下 正常...
  • JVM 调优案例分析1

    千次阅读 2015-11-02 17:41:45
    JVM 调优 1 案例资料  案例程序在stock.zip中http://download.csdn.net/detail/jingshuaizh/9234175  Requirements jdk1.7 mysql 5.1 import db.sql 修改stock.bat 关于数据库的连接配置   2 调优目标 目标...
  • JVM:JVM调优案例记录

    2018-12-25 10:39:24
    https://blog.csdn.net/ityouknow/article/details/79078249
  • JVM调优案例详解及面试题

    千次阅读 2020-06-14 16:33:20
    JVM调优目的 减少STW (Stop The Work),减少full gc的次数和缩短full gc的时间 一个4核8G的订单系统,假设给JVM运行内存为3个G,按照上图比例老年代可分2G,Eden 800M,S0,S1各100M,线程运行每秒产生60M对象,大概运行13...
  • jvm调优案例总结

    2018-11-11 22:17:18
  • JVM调优案例分析与实战

    千次阅读 2016-11-28 16:47:26
    模拟代码以及JVM设置: public class OOMTest {  //JVM设置  //-Xms30M -Xmx30M -Xmn10M -XX:+PrintGCDetails -XX:PermSize=10m -XX:MaxPermSize=10m -XX:+UseConcM
  • 二、JVM参数设置和JVM内存模型 1、JVM参数设置 -Xms 3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M 2、JVM内存模型 内存模型图说明 内存大小设置为3G,默认老年代和年轻代的大小为2:1...
  • JVM调优案例分析与实战(1):高性能硬件上的程序部署策略 本JVM系列均来源于《深入理解Java虚拟机》一书中,版权归该书作者所有。 环境:一个15万PV/天左右的在线文档类型网站最近更换了硬件系统,新系统硬件为...
  • GC常用参数 -Xmn -Xms -Xmx -Xss 年轻代 最小堆 最大堆 ...-XX:PreBlockSpin 热点代码检测参数-XX:CompileThreshold 逃逸分析 标量替换 … 这些不建议设置 JVM调优第一步,了解JVM常用命令行参数 JVM的命令行参数参考:...
  • 案例分析高性能硬件上的程序部署策略例 如 ,一个15万PV/天左右的在线文档类型网站最近更换了硬件系统,新的硬件为4个CPU、16GB物理内存,操作系统为64位CentOS 5.4 , Resin作为Web服务器。整个服务器暂时没有部署别的...
  • 案例分析 高性能硬件上的程序部署策略 例 如 ,一个15万PV/天左右的在线文档类型网站最近更换了硬件系统,新的硬件为4个CPU、16GB物理内存,操作系统为64位CentOS 5.4 , Resin作为Web服务器。整个服务器暂时没有部署...
  • 环境:一个基于B/S的MIS系统,硬件为2个CPU、8GB内存的HP系统,服务器是WebLogic9.2(就是第二个案例中的那个系统)。正常运行一段时间后,最近发现在运行期间频繁出现集群节点的虚拟机进程自动关闭的现象,留下一个hs...
  • 参考:http://www.cnblogs.com/royi123/p/3521043.html
  • 而本案例中使用的Comet1.1.1框架,正好有大量的NIO操作需要用到Direct Memory。 总结:从实践经验来看,除了java堆和永久代之外,我们注意到下面这些区域也会占用较多的内存,这里所有的内存总和会受到操作系统进程...
  • 而本案例中使用的Comet1.1.1框架,正好有大量的NIO操作需要用到Direct Memory。 总结:从实践经验来看,除了java堆和永久代之外,我们注意到下面这些区域也会占用较多的内存,这里所有的内存总和会受到操作系统...
  • 环境:这是一个来自网络的案例:一个数字校园应用系统,运行在一台4个CPU的Solaris 10操作系统上,中间件为ClassFish服务器。系统在进行大并发压力测试的时候,发现请求响应时间比较慢,通过操作系统的mpstat工具...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 563
精华内容 225
关键字:

jvm调优案例