<<上篇 | 首页 | 下篇>>

JVM系列四:生产环境参数实例及分析【生产环境实例增加中】 - redcreen - 博客园

java application项目（非web项目）

改进前：

-Xms128m
-Xmx128m
-XX:NewSize=64m
-XX:PermSize=64m
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=78
-XX:ThreadStackSize=128
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true
问题:
  1. permsize 设置较小,很容易达到报警范围(0.8)
  2. 没有设置MaxPermSize，堆增长会带来额外压力。
  3. NewSize较大，old gen 剩余空间64m，一方面可能会带来old区容易增长到报警范围（监控数据显示oldgenused长期在50m左右，接近78%，容易出现full gc）,另一方面也存在promontion fail风险
改进后：
-Xms128m
-Xmx128m
-Xmn24m
-XX:PermSize=80m
-XX:MaxPermSize=80m
-Xss256k
-XX:SurvivorRatio=1
-XX:MaxTenuringThreshold=20
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSParallelRemarkEnabled
-XX:CMSFullGCsBeforeCompaction=2
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true
修改点：
  1. PermSize与MaxPermSize都设置为80，一方面避免non heap warn(报警阀值0.8 非对内存一般占用到60M以内），一方面避免堆伸缩带来的压力
  2. 通过设置Xmn=24M及SurvivorRatio=1 使得Eden区=from space=to  space=8M,降低了Eden区大小，降低YGC的时间(降低到3-4ms左右),同时通过设MaxTenuringThreshold=20，使得old gen的增长很缓慢。带来的问题是YGC的次数明显提高了很多。
  3. 其他参数优化 修改后带来的好处见JVM参数设置
再次改进后
-Xms128m
-Xmx128m
-Xmn36m
-XX:PermSize=80m
-XX:MaxPermSize=80m
-Xss256k
-XX:SurvivorRatio=1
-XX:MaxTenuringThreshold=20
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=73
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSParallelRemarkEnabled
-XX:CMSFullGCsBeforeCompaction=2
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true
修改点：

      在上面的基础上调整Xmn大小到36M，设置CMSInitiatingOccupancyFraction=73。

      Dden区与Survivor区大小都增加到12M，通过CMSInitiatingOccupancyFraction计算公式,计算得出value为73是，可以避免promotion faild问题，同时满足堆内存监控报警值在80%：内存大小128M*80%=102.4M 102.4M-36M=66.4M(老生代达到此值报警） 老生代达到67.15M（92M*0.73）将发生Full GC，所以在老生代大小达到66.4M时也就是WARN报警时将很有可能出现Full GC。
       增大了Eden和Survivor区的值，会减小YGC的次数，但由于空间变大理论上也会相应的增加YGC的时间，不过由于新生代本身就很小（才36M）这点儿变化可以忽略掉。实际的监控值显示YGC的时间在4-5ms之间。是可以接受范围。
      SurvivorRatio 这个值还得在仔细考虑下,有待优化中
 
网上某个牛人的配置 :每天几百万pv一点问题都没有，网站没有停顿
$JAVA_ARGS
.=
"
-Dresin.home=$SERVER_ROOT
-server
-Xms6000M
-Xmx6000M
-Xmn500M
-XX:PermSize=500M
-XX:MaxPermSize=500M
-XX:SurvivorRatio=65536
-XX:MaxTenuringThreshold=0
-Xnoclassgc
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:-CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=90
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log
";

说明一下， -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0就是去掉了救助空间； 

-Xnoclassgc禁用类垃圾回收，性能会高一点； 

-XX:+DisableExplicitGC禁止System.gc()，免得程序员误调用gc方法影响性能； 

-XX:+UseParNewGC，对年轻代采用多线程并行回收，这样收得快； 

带CMS参数的都是和并发回收相关的，不明白的可以上网搜索； 

CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotion failed。在我的应用中Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是年老代有5500兆，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还剩10%的空间是5500*10%=550兆，所以即使Xmn（也就是年轻代共500兆）里所有对象都搬到年老代里，550兆的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的promotion failed； 

SoftRefLRUPolicyMSPerMB这个参数我认为可能有点用，官方解释是softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap，我觉得没必要等1秒； 

-Xmx4000M
-Xms4000M
-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=80
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log

改进方案：

上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotion failed。
具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。

 

某网友:
$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
";
64位jdk参考设置，年老代涨得很慢，CMS执行频率变小，CMS没有停滞，也不会有promotion failed问题，内存回收得很干净
 

阅读全文……

标签 :
发表评论 RSS feed for responses to this blog entry
IT瘾于2014年4月14日 下午06时17分00秒发布 #

Apache Tika - Apache Tika

The Apache Tika™ toolkit detects and extracts metadata and structured text content from various documents using existing parser libraries. You can find the latest release on the download page. See the Getting Started guide for instructions on how to start using Tika.

支持的文件格式有：

Supported Document Formats

This page lists all the document formats supported by Apache Tika 0.6. Follow the links to the various parser class javadocs for more detailed information about each document format and how it is parsed by Tika.

阅读全文……

标签 :
发表评论 RSS feed for responses to this blog entry
IT瘾于2014年4月14日 下午05时35分00秒发布 #

OpenSSL 的 Heartbleed 漏洞的影响到底有多少？ - 知乎

既然大家都这么关注，那么我就再爆点猛料好了。
我一骇客界的朋友Lwqn跟我说他们一年前就已经在利用这个漏洞了，获取到了不少大网站的敏感数据，这个消息让我彻夜难眠。

他发了一个exploit的demo给我，原链接已经撤掉了，所以我放到了gist上：http://gist.github.com/RixTox/10222402 Pyhton3版的在这里OpenSSL heartbeat PoC with STARTTLS support

下图是对DEF CON进行的Heartbleed测试
DEF CON在我测试完一个小时后已修复此漏洞。

事实证明此漏洞的确会造成严重的memory dump，因为与所有OpenSSL数据共享同一块内存，dump出来的有可能是任何内容：用户请求、密码，甚至是服务器的私钥！只要不断进行攻击就很有可能拿到关键的数据。

这是一个很严重的漏洞，涉及开启了Heartbeat扩展的OpenSSL版本1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1
OpenSSL: OpenSSL vulnerabilities
刚才在我们的服务器（Gentoo）上看了一下，用的正是1.0.1c的受威胁版本，不过我们并没有开启Heartbeat，所以并不会受到实际威胁，但还是打上了补丁，以备不时之需。
Add heartbeat extension bounds check. 路 7e84016 路 openssl/openssl 路 GitHub
如果你只是想检测一下你的服务器受不受威胁，现在有一款现成的工具可以用
titanous/heartbleeder 路 GitHub
也可以直接使用下面的OpenSSL命令来判断

/usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'


这个命令只告诉你是否有启用Heartbeat，但并不能说明是否受到威胁，还需要结合OpenSSL的版本进行判断。

Hacker News上面有人给出了这段脚本，能检测Alexa Top Million网站开启Heartbeat的服务器

INPUT=websites.csv OLDIFS=$IFS IFS=, [ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; } while read rank website do   echo "checking $website for heartbeat..."   echo -e "quit\n" | /usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1' done < $INPUT IFS=$OLDIFS

Download Alexa Top 1,000,000 Websites for Free
I wrote a bash script to check the top 1000 websites and huge percentage of them...
跑了一小会儿，但好像并没发现什么有价值的信息。其实Heartbeat作为CRM在OpenSSL中用到的机会本就不多，再加上大网站的反应都很迅速，不容易出现大的纰漏。至于0Day发布之前有没有被人利用就不得而知了。

阅读全文……

标签 : ,
发表评论 RSS feed for responses to this blog entry
IT瘾于2014年4月10日 下午06时50分00秒发布 #