[Jboss瘦身和调优.docVIP

JBoss AS的调优与瘦身 基于JBoss 3.2.6 。 FOR 4.0.4+修订版 JBoss4瘦身 前言 这个建议主要是如果对JBossAS进行调优和瘦身的. 这个概念在多数情况是交叉的。当通过瘦身减少闲置服务线程并不能带来大的性能影响的时候，允许你使用较少的内存和资源对其他性能方便进行调整。当然它可以缩短启动时间。而且，作为一般的安全观念――移除你不使用的服务。我们将分开两个种类: 瘦身和调优. 首先我们使用默认的配置并从那里开始瘦身(对于clustering的话题，将在以后的wiki页面进行讨论 ;-) ). 这个建议不牵扯开发者和管理角色交叉调优的区域开发者和管理角色 (应用程序调优象cache大小一样). 这主要是对于管理调优的建议. 这建议将做技术上非J2EE平台兼容(3.2.6无论如何不顺从)的JBoss实例的有关的那些注意，象除去J2EE关键 服务的那样将导致JBoss 失败TCK。多数性能调优/管理任务工作，在现实世界结构里，在技术上属于这个类别。 假设你已经复制server/default 文件夹并将它重新命名为server/slim. 调优 Java Virtual Machine Java虚拟机 ???对于你的机器和内存大小来调整VM垃圾收集或者调整 JDK 5 的垃圾收集???使用64位的机器和64位的VM，以便你能使用大的heap(堆)大小，通常比2－4GB的大。64位支持在所有最新的SPARC/Solaris 寄存器运行Solaris 9 或者以后的版本是有效的, Itanium 使用 JDK 1.4, 或者在Linux x64 上使用JDK 5. ???如果你不使用上面的最大32位heap空间(2-4 GB 的heap)，不要使用 –d64. 使用64位地址需要更多的内存来做同样的工作量，并且对于应用程序不需要如此多的内存来说并不能提供更大优势。 ???除了避免额外小的heaps外还要避免额外大的heaps. (我们不能告诉你具备什么资格，因为它取决于你正做什么). 这影响generational 垃圾收集和扫描heap的总的时间. 有效的调整一个小heap是困难的 (即使你的应用程序仅仅需要使用200MB，如果你使用并行垃圾收集＋CMS，然后你将需要远高于512MB). 特大号的heaps为垃圾收集花费不必要的时间扫描内存。 ???避开 Sun 1.4 VM. JDK 5 主要是在垃圾收集方面非常的好. ???使用 -server 参数除了使用其他-XX:ThreadStackSize=128k (Solaris) 或者 -Xss128k (其他任何平台). 在Solaris 上 -Xss128k 什么也没有做 (你只可以设置较大的线程栈大小). 这允许你每个线程通过使用较少的内存达到创建更多线程的目的。but might result in blown stacks with extremely recursive code. 然而, 128k 栈 is still nothing to shake a stick at. ???你真的需要明白恰当的generational 垃圾收集调整和你真的已经进行了负载测试 (OpenSTA?, JMeter, 等等) 确认是有把握的. ???你确实将使用一个超过2个处理器的多核心机器，及使用不同的平行和并行垃圾收集选择 (我们谈及这先进的JBoss训练暗示伏笔) 对于最大性能和高拉机回收吞吐量. 不过,你确实需要理解怎么调整才能使得垃圾收集很好的工作。JDK 5大部分是自我调整. ???JDK 1.4的默认 NewSize? 不是好的猜想. 坏的经验法则: 20% 是一个好的 NewSize?. 20%以上的消费是危险的，这是JDK令人讨厌的一个，能导致它psychotically运行所有满垃圾回收和从未 unsuspend 或者释放出 足够多的内存. JDK 5 似乎没有展示出这个bug，并且似乎已回升更理智的默认值。 JBoss/Java on Linux ? 如果你正在运行JBoss AS在Linux服务器上，你应该看看这篇文章的作者： Andrew Oliver, Jboss事业部, Red Hat公司, 顾问 ，在 在Linux服务器上怎么优化Jboss/Java Tomcat ???编辑你的server/slim/jbossweb-tomcat5?.sar/server.xml 文件 ???检查你正在使用的连接器的XML文档. 例如, HTTP 连接器: Connector port=8080 address=${jboss.bind.address} maxThreads=150 m