Nginx+resin调优文档

http://blog.liuts.com/post/204/

 

 

 为什么不选择Apache/mod+resin?
       前面一直使用该模式,mod_caucho暴露源码的bug一直未得到彻底的解决。因此切换到Nginx+resin平台。硬件上要求除了内存一定要足够大(建议>4G),无其它要求(当然也不能太破,呵呵sweat)。操作系统强烈要求安装64位,32位操作系统jvm只能识别不到2G的内存,印象中是1.57G(单实例应用)。下面总结自己的一些调优方法及配置。

调优硬件环境


CPU:Intel Xeon*2(双核)
MEM:8G
SWAP:1G


一、测试32系统所支持的最大可用内存
java -XmxXXXXM -version
不断加大-Xmx的大小,截止到出现以下提示:
Could not create the Java virtual machine.

二、Nginx配置


   location / {
     root /var/www/app.cn;
     index index.jsp;
     proxy_pass http://localhost:8080;
     include /usr/local/nginx/conf/proxy.conf;
   }

   location ~* \.(jsp|do|shtml)$ {
     root /var/www/app.cn;
     index index.jsp;
     include /usr/local/nginx/conf/proxy.conf;
     proxy_pass http://localhost:8080;
     proxy_set_header X-Real-IP $remote_addr;
   }


      以代理的方式进行整合,静态文件继续由Nginx来解析,扩展名为jsp|do|shtml才丢给后端resin来处理。即使resin发现的故障,前端最多只会报500、502 time out的信息。

三、resin配置

1、jvm的优化
#vi $resin_root/bin/httpd.sh

  1. args="-Xmx6048m -Xms6048m -Xmn2g -Xss128k -XX:NewSize=256m -XX:MaxPermSize=512m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31 -Dsun.net.inetaddr.ttl=60"  

args="-Xmx6048m -Xms6048m -Xmn2g -Xss128k -XX:NewSize=256m -XX:MaxPermSize=512m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31 -Dsun.net.inetaddr.ttl=60"
    1.1、Xmx与Xms建议配置一致,避免每次垃圾回收完成后JVM 重新分配内存。预留2G左右的内存空间给Nginx与OS就差不多了。
    1.2、Xmn配置成Xmx的1/3。
    1.3、Dsun.net.inetaddr.ttl=60,java对DNS解析域名结果进行缓存,默认超时时间为-1(在重启JVM前永久缓存),如有涉及域名解析失效需修改该值。

2、resin并发数限制
免费的resin是没有pro的授权,并发连接数(默认512)配置参数不可见。因此通过修改源码达到突破限制的目的。
1、修改方法:
    1.1、下载resin3.0.22源码;
    1.2、修改resin-3.0.22/modules/resin/src/com/caucho/server/port/Port.java


            // default timeout
            private long _timeout = 65000L;
            private int _connectionMax = 512;修改成20480
            private int _minSpareConnection = 16;
            private int _keepaliveMax = -1;
            private int _minSpareListen = 5;
            private int _maxSpareListen = 10;


    1.3、将编译后的Port.class覆盖原 /lib/resin.jar包。

2、可以从resin-status结果得到证实
点击在新窗口中浏览此图片
                                                       [编译前]
---------------------------------------------------------------------------------------------------------------------------
点击在新窗口中浏览此图片
                                                       [编译后]

3、resin.conf配置

  1. <dependency-check-interval>-1</dependency-check-interval>   

<dependency-check-interval>-1</dependency-check-interval>
生产环境建议关闭自检查 ,原因是会消耗系统一定资源及部分更新会出现不可意料的错误。

  1. <!-- Maximum number of threads. -->   
  2. <thread-max>20480</thread-max>   

<!-- Maximum number of threads. --> <thread-max>20480</thread-max>
建议与private int _connectionMax参数保持一致。

       其它参数需根据应用的具体情况来调整,如长链接超时等。以上为本人整理一些调优笔记,如有遗漏或纠正请与我联系。

Tags: resin , 调优
kim
2010/09/04 16:36
我的thread上到2000,基本上就假死了。
刘天斯 回复于 2010/09/05 19:54
跟应用有很大的关系。
陈子
2010/07/19 15:25
location / {
     root /var/www/app.cn;
     index index.jsp;
你看下面这句?
     proxy_pass http://localhost:8080;
     include /usr/local/nginx/conf/proxy.conf;
   }
刘天斯 回复于 2010/07/19 19:55
这两行可以去掉。
陈子
2010/07/18 19:24
nginx配置里把所有的都透传给resin了呀?
刘天斯 回复于 2010/07/18 20:09
不是的,只是jsp、do、shtml扩展名,静态文件还是由Nginx负责处理。
分页: 1/1 第一页 1 最后页
1.JVM的gc概述 gc即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc,也没有规定gc如何工作。不过常用的jvm都有gc,而且大多数gc都使用类似的算法管理内存和执行收集操作。 在充分理解了垃圾收集算法和执行过程后,才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如,实时应用程序主要是为了避免垃圾收集中断,而大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和jvm支持的垃圾收集算法,便可以进行优化配置垃圾收集器。 垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。gc首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。 1.1.引用计数 引用计数存储对特定对象的所有引用数,也就是说,当应用程序创建引用以及引用超出范围时,jvm必须适当增减引用数。当某对象的引用数为0时,便可以进行垃圾收集。 1.2.对象引用遍历 早期的jvm使用引用计数,现在大多数jvm采用对象引用遍历。对象引用遍历从一组对象开始,沿着整个对象图上的每条链接,递归确定可到达(reachable)的对象。如果某对象不能从这些根对象的一个(至少一个)到达,则将它作为垃圾收集。在对象遍历阶段,gc必须记住哪些对象可以到达,以便删除不可到达的对象,这称为标记(marking)对象。 下一步,gc要删除不可到达的对象。删除时,有些gc只是简单的扫描堆栈,删除未标记的未标记的对象,并释放它们的内存以生成新的对象,这叫做清除(sweeping)。这种方法的问题在于内存会分成好多小段,而它们不足以用于新的对象,但是组合起来却很大。因此,许多gc可以重新组织内存中的对象,并进行压缩(compact),形成可利用的空间。 为此,gc需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止,只有gc运行。结果,在响应期间增减了许多混杂请求。另外,更复杂的gc不断增加或同时运行以减少或者清除应用程序的中断。有的gc使用单线程完成这项工作,有的则采用多线程以增加效率。 2.几种垃圾回收机制 2.1.标记-清除收集器 这种收集器首先遍历对象图并标记可到达的对象,然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。 2.2.标记-压缩收集器 有时也叫标记-清除-压缩收集器,与标记-清除收集器有相同的标记阶段。在第二阶段,则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。 2.3.复制收集器 这种收集器将堆栈分为两个域,常称为半空间。每次仅使用一半的空间,jvm生成的新对象则放在另一半空间中。gc运行时,它把可到达对象复制到另一半空间,从而压缩了堆栈。这种方法适用于短生存期的对象,持续复制长生存期的对象则导致效率降低。 2.4.增量收集器 增量收集器把堆栈分为多个域,每次仅从一个域收集垃圾。这会造成较小的应用程序中断。 2.5.分代收集器 这种收集器把堆栈分为两个或多个域,用以存放不同寿命的对象。jvm生成的新对象一般放在其中的某个域中。过一段时间,继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。 2.6.并发收集器 并发收集器与应用程序同时运行。这些收集器在某点上(比如压缩时)一般都不得不停止其他操作以完成特定的任务,但是因为其他应用程序可进行其他的后台操作,所以中断其他处理的实际时间大大降低。 2.7.并行收集器 并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。 3.Sun HotSpot 1.4.1 JVM堆大小的调整 Sun HotSpot 1.4.1使用分代收集器,它把堆分为三个主要的域:新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后,便获得使用期并进入旧域。在永久域中jvm则存储class和method对象。就配置而言,永久域是一个独立域并且不认为是堆的一部分。 下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。 下面的命令是把初始大小设置为128M: java –Xms128m –Xmx256m为控制新域的大小,可使用-XX:NewRatio设置新域在堆中所占的比例。 下面的命令把整个堆设置成128m,新域比率设置成3,即新域与旧域比例为1:3,新域为堆的1/4或32M: java –Xms128m –X
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值