resin的JVM參數調整

<!-- - JVM 参数设置 --> <jvm-arg>-Xms 2048 m</jvm-arg> （ jvm 最小内存，也是启动 resin后的默认内存分配值） <jvm-arg>-Xmx 2048 m</jvm-arg> <!-- make ms=mx to reduce GC times --> （ jvm最大内存，当内存使用超过 Xms分配的值之后会自动向这个最大值提升，一般配置成最大最小值相等，理论上能够降低 GC 垃圾收集的时间，可按实际进行配置） <jvm-arg>-Xmn 512 m</jvm-arg>

（内存分配增量，当内存需求超过 Xms值之后进行第一次分配请求的内存值，一般为 Xmx的 1/3-1/4 ；开始时候可以先屏蔽，当应用出现OutOfMemory的时候再打开也可以）

<jvm-arg>-XX:MaxNewSize= 256 m</jvm-arg> <jvm-arg>-XX:PermSize= 128 m</jvm-arg> <jvm-arg>-XX:MaxPermSize= 256 m</jvm-arg> （以上三项是为了减少 OutOfMemory 而配置的，是每个 java编译执行的时候最多能一次申请 jvm 内存空间的值，以上默认配置基本够用，但依然出OutOfMemory 的时候可以适当调大，但不能超越 Xmx的值；开始时候可以先屏蔽，当应用出现 OutOfMemory的时候再打开也可以）

<jvm-arg>-Xss256k</jvm-arg> <!-- jvm Stack config -->

(单 个线程 堆栈 占的内存量)

<jvm-arg>-Djava.awt.headless=true</jvm-arg> < （允许使用验证码） <jvm-arg>-Djava.net.preferIPv4Stack=true</jvm-arg> <!-- disable IPv6 --> <jvm-arg>-Doracle.jdbc.V8Compatible=true</jvm-arg>（针对 oracle10的兼容配置） <watchdog-arg>-Dcom.sun.management.jmxremote</watchdog-arg>

<!-- 强制 resin 强制重起时的最小空闲内存 --> <memory-free-min> 2 M</memory-free-min>

<!-- 最大线程数量 . --> <thread-max>1024</thread-max>

<!-- 套接字等待时间 --> <socket-timeout>30s</socket-timeout>

<!-- 配置 keepalive --> <keepalive-max>512</keepalive-max> <keepalive-timeout>60s</keepalive-timeout>

Resin 中 JVM 的分析 JVM 虚拟内存

JVM 虚拟内存与系统内存的关系图：

-Xms 初始化 jvm 的时候从系统内存划分的 heap 内存数量 -Xmx jvm 最大能使用的 heap 内存数量 -Xmn （ -XX:NewSize/ -XX:MaxNewSize ）年轻代占 heap 的内存数量 -XX:PermSize / -XX:MaxPermSize 持久代占用的系统内存数量 -Xss 单 个线程 堆栈 占的内存量，跟线程数相关 整个 JVM 的工作流程是：新的线程在 Eden 生成； Eden 满，把有经常访问的资 源放在 SO1 中，对 Eden 进行空间回收；当 SO1 满，将常使用的资源放到 SO2 ，对 SO 1 的空间进行回收；当 SO2 满，将经常访问的资源放到 Old ，对 SO2 进行空间回收； 按一定的规则对 Old 的资源进行处理。（为了容易记忆，我们可以对 SO1 、 SO2 、 O ld 起个其他的名字，分别是 幸存者 1 区，幸存者 2 区和养老区 ） 简单概括为： Heap 设定与垃圾回收 Java Heap 分为 3 个区， New ， Old 和 Permanent 。 New 保存刚实例化的对象。当该区被填满时， GC 会将对象移到 Old 区 。 Permanent 区则负责保存反射对象。 （ Perm 区在过去持久化没有使用的年代默认 的 配置已经足够使用，但现在要注意该区的情况，有可能 OOM--out of menery 就 是由于它而发生） 从上面的 JVM 工作机制，我们可以看出对 JVM 的优化主要在于： JVM-- 垃 圾收集。 注意： Heap 大小并不决定进程的内存使用量。进程的内存使用量要大于 -Xmx 定义的值， 因为 Java 为其他任务分配内存，例如每个线程的 Stack 等。

日常遇到的OOM和频繁发生GC 情况分析

java.lang.OutOfMemoryError: Java heap space

heap 空间不足，可能是 -Xmx 配得过大，或者系统内存不足或泄漏

java.lang.OutOfMemoryError: PermGen space

持久代内存不足，存在大量系统类被加载或 jpa 等架构频繁使用，需要增加 Perm的内存配置

java.lang.OutOfMemoryError:unable to create native thread

空闲内存不足以建立新的线程，减少 max-threads 的配置，增加空闲内存数量

为什么一些程序频繁发生 GC ？有如下原因： 1. 程序内调用了 System.gc() 或 Runtime.gc() 。 2. 一些中间件软件调用自己的 GC 方法，此时需要设置参数禁止这些 GC 。 3. Java 的 Heap 太小，一般默认的 Heap 值都很小。 4. 频繁实例化对象， Release 对象。此时尽量保存并重用对象，例如使用StringBuffer() 和 String() 。 5. 如果你发现每次 GC 后， Heap 的剩余空间会是总空间的 50% ，这表示你的 Heap 处于健康状态。 在 Resin 中对 JVM 的优化能很好的提高 Resin 的性能，通过这些基本知识使你对Resin 中 JVM 的优化更有把握。

Resin中除JVM外的优化 在实际的生产环境中，以下三个东西经常用到，所以在这里提一下，也算是简单的优化。 <thread-max>512</thread-max> 最大线程数影响 resin 的系统负载能力以及 java 进程的内存占用 <keepalive-max>128</keepalive-max> keepalive 的最大数量，对网络性能有影响 js/html/css/jpg/gif 等静态文件由 nginx 提供服务，剩下的由nginx以upstream方式代理到后端resin处理，以减少resin 提供这些静态文件访问的性能问题。 R esin 及 jvm 优化，是一项基于提供服务的应用上进行一段相对长时间的测试进行，由于每个项目都有其自身特点，只有根据这些特点来进行优化，才能把该项目配置得更好 ，不可能硬套到其它项目上 。