JBOSS使用
程序员文章站
2022-05-06 14:05:54
...
1.创建Jboss虚拟目录配置
%JBOSS_HOME%/server/default/deploy/jboss-web.deployer/server.xml
<Host name="localhost"
autoDeploy="false" deploy deployXML="false">
<!-- Uncomment to enable request dumper. This Valve "logs interesting
contents from the specified Request (before processing) and the
corresponding Response (after processing). It is especially useful
in debugging problems related to headers and cookies."
-->
<!--
<Valve className="org.apache.catalina.valves.RequestDumperValve" />
-->
<!-- Access logger -->
<!--
<Valve className="org.apache.catalina.valves.FastCommonAccessLogValve"
prefix="localhost_access_log." suffix=".log"
pattern="common" directory="${jboss.server.home.dir}/log"
resolveHosts="false" />
-->
<!-- Uncomment to enable single sign-on across web apps
deployed to this host. Does not provide SSO across a cluster.
If this valve is used, do not use the JBoss ClusteredSingleSignOn
valve shown below.
-->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Uncomment to enable single sign-on across web apps
deployed to this host AND to all other hosts in the cluster
with the same virtual hostname.
If this valve is used, do not use the standard Tomcat SingleSignOn
valve shown above.
This valve uses JGroups to communicate across the cluster. The
JGroups Channel used for this communication can be configured
by editing the "sso-channel.xml" file found in the same folder
as this file. If this valve is running on a machine with multiple
IP addresses, configuring the "bind_addr" property of the JGroups
UDP protocol may be necessary. Another possible configuration
change would be to enable encryption of intra-cluster communications.
See the sso-channel.xml file for more details.
Besides the attributes supported by the standard Tomcat
SingleSignOn valve (see the Tomcat docs), this version also supports
the following attribute:
partitionName the name of the cluster partition in which
this node participates. If not set, the default
value is "sso-partition/" + the value of the
"name" attribute of the Host element that
encloses this element (e.g. "sso-partition/localhost")
-->
<!--
<Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn" />
-->
<!-- Uncomment to check for unclosed connections and transaction terminated checks
in servlets/jsps.
Important: You need to uncomment the dependency on the CachedConnectionManager
in META-INF/jboss-service.xml
<Valve className="org.jboss.web.tomcat.tc5.jca.CachedConnectionValve"
cachedC
transacti />
-->
<!--部署虚拟目录-->
<!-- <Context path="/test" docBase="E:\StudyWork\lianlianAward\WebRoot" reloadable="true" debug="0"> </Context>
--></Host>
调整JBOSS应用服务器
1. 定义性能
性能包括多个方面，如响应时间、吞吐量及服务等级协议(Service Level Agreements，SLAs）等。性能的另一个方面涉及系统如何扩展来满足不断增长的工作负载。
响应时间表示系统对用户请求做出响应的时间。处理时间为系统最初收到请求到系统返回响应所用的时间。往返响应时间包括延迟，它是将请求从输入设备发送到系统并返回所用的时间。因此，响应时间总是比处理时间长，而且取决于用户和系统之间的通信网络状态。
吞吐量表示系统可以处理的请求数量，常用一个给定时间之内的请求处理量来表示。
服务等级协议是一个在供应商（托管或提供一个应用程序或系统）与客户（使用这个系统）之间提供某一个等级服务的合同，服务等级协议确保供应商及时提供足够的资源来处理客户的请求，如果系统没能满足服务等级协议目标，供应商将保证进行金钱赔偿。
扩张涉及是否及如何将附加负载添加到系统中。有两种扩展方法：纵向扩展（也被称为垂直扩展）和横向扩展（也被称为水平扩展）可以做到。纵向扩展指得是向一个现有的计算机添加更多的资源来应付增加的负载；而横向扩展指的是给系统增加更多的计算机来处理更多的计算机来处理更多的负载。
2.性能调整方法
在做任何调整之前，应该首先拥有一个能定义吞吐量和/或响应时间要求的服务等级协议，这是因为如果系统已经满足客户要求的性能，就没有必要花费时间和金钱来调整系统了。
服务等级协议是从终端用户的角度定义和用于评估整个系统（包含网络、操作系统、应用服务器、数据库服务器和应用程序）的。
如果想调整造成系统瓶颈的组件，可以采用如下各种方法
| 调整方法 | 示例 |
| 修改配置参数 | （1）修改命令行的参数至JVM （2）在数据源配置文件里修改数据库连接池的大小 |
| 添加或修改硬件 | (1) 添加另一个磁盘控制器到数据库服务器来更好地并行访问这个磁盘 （2）向运行应用服务器的计算机添加更多的内存 （3）用1GB的网卡代替100MB的网卡 |
| 修改应用程序或数据库 | （1）在应用程序代码里修改一个关键算法 （2）在数据库里向一个表添加索引 （3）部署到缓存以减少针对数据库的查询 |
3.性能分析测试周期
测试扩展功能的是时候，首先使单个应用服务器实例运行至极限，然后让两个应用服务器运行至极限，等等。那时，才能了解系统的扩展功能，也会知道通过添加另一个应用服务器到生成配置可以支持多少额外通信量。
3.1 创建测试脚本
确定想要什么数据后建立用于收集这种数据的工具，可以使用Windows的性能监控器或LInux和Unix系统的Top实用工具。用于驱动测试的工具（如JMeter)也提供性能数据。
4. 分析周期：运行、分析并调整
每次只做一个修改。如果做了不止一个修改，将永远不知道是哪个修改引起了测试结果的变化，或是不是这些修改互相抵消了。除非拥有足够的经验和知识，否则不要在运行测试之前做出超过一个的修改。
5. 调整硬件和网络
可以使用mii-tool或ethtool命令（必须使用root来运行任意一个命令）来在大多数linux版本上设置网卡的速度。使用-v命令行选项可以修改网卡的当前设置和允许的网络速度。
mii-tool -v
可以在上述命令输出的结果上将网卡速度设置为100Mbps，具体如下：
mii-tool -F 100baseTX-FD eth0
应该将速度设置为与网络相匹配。在这个示例中，网络必须在全双工的情形下每秒传输100MB数据，如果网卡不能与网络速度相匹配，只有在改正这个速度后的网络连接才能建立。
5.1 选择cpu的数量
选择32位或64位的CPU，对于32位的操作系统，如果只运行一个单独的应用服务器，2GB内存一般就够了。在2GB内存的环境下可以分配1.4GB的堆，即使拥有更多的内存，也不能分配一个更大的堆。在一个32位的操作系统上，每一个进程一般只有4GB地址空间。操作系统一般为其自己的用途(如文件缓冲区、线程信息、及其他操作系统运行进程必要的数据）保留2GB空间。Java堆最终会与JVM和其他各种操作系统及JVM使用的语言库分享剩下的2GB。此外，大多数JVM要求用连续的内存块来分配堆。实际极限一般在1.4GB左右，但不同操作系统及其版本的情况也不尽相同。
对于64位的操作系统，需要更大的内存，因为字节更长，使用的空间就更大。根据经验，启动计算机并留心配置内存的总大小。将堆增加到需要的大小并保证有至少与其大小相同的内存。一般来说4GB就足够了，大型堆需要更多的资源回收时间，这可能会导致应用程序的长时间停顿。
5.2 调整操作系统性能
监视一个系统的时候，保证cup的平均使用率不要超过80%，理想的利用率应处于50%～80%之间。如果让系统超负载运转，性能肯定会下降。
调整操作系统一个明显的调整措施是禁用所有不需要的服务，所有这些服务都会消耗内存和处理器带宽，而这些资源都可以被应用服务器使用。
如果运行应用服务器的计算机只包含一个或两个处理器，那么就应该注意以上的所有建议；如果这个计算机拥有4个或更多个处理器，就应该考虑处理器关联的问题了。
5.3 理解处理器关联
大多数支持多个处理器的操作系统都会提供一个机制来限制运行某个给定程序的多个处理器，这个功能被称为处理器关联。
对于运行linux的多处理器计算机，可以使用taskset工具来设置处理器关联。例如，如果应用服务器正在一个8CPU计算机上作为进程9999运行，可以通过使用下列命令来声明应用服务器只使用4个处理器：
taskset -p 0x0f 9999
服务器缓冲的原理：当处理器在处理一个线程的时候，线程使用的数据和代码会被存储在该处理器的缓冲中。当线程被中断的时候（等待如I/O事件的时候被阻塞或用完了它的分配时间），另一个线程会与性并开始覆盖那些已被缓存的代码和数据。如果缓存空间足够大，在线程重新返回相同处理时，一些代码或数据可能依然被缓存。如果线程被分配到一个不同的处理器上，那么这个线程就必须重新填充缓存。访问被缓存的数据比内存中访问数据要快好多倍。
对于一般的java应用程序和应用服务器，一个java应用程序一般在堆中执行针对创建对象的数据访问。由于活动数据被存储在处理器缓存中，如果线程继续被分配到相同的处理器，这个缓存可能会包含对象数据。如果线程被分配到一个不同的处理器上，那么线程就必须从内存中重新加载数据。
设置处理器关联
测试表明应该将2～4个处理器分配至应用服务器以使其获得最佳性能，具体的数量取决于被部署至应用服务器上的应用程序。在一般情况下，对公共数据依赖性比较大的应用程序在两个服务器上运行得更好；而一个更为独立的应用程序在4个服务器上运行的更好。可以分别在2、3或4个处理器上测试应用程序并选出最好的处理器关联。
不能将处理器关联的建议理解成java应用程序不能扩展，很多java应用程序都可以扩展到2个、64个甚至更多个处理器。这类应用程序倾向于运行独立的线程。应用服务器必须管理许多被所有线程访问的共享对象。应用服务器没有专用于单一任务的线程（大多数线程处理用户请求，每一个都与其他线程差异巨大）而且难以扩展到4个以上的处理器。
测试表明javaEE应用服务器可以很容易地扩展到4个物理处理器，而不管其是单核处理器还是双核处理器。如果具有双核处理器，就可以将一个应用服务器扩展到8个逻辑处理器（4个双核物理处理器）。
调整JVM
有两种被指定为服务器虚拟机和客户端虚拟机的HotSpot JVM，可以使用-client和-server命令行参数调用。它们之间的区别主要在于如何将java字节码编译成机器码和如何管理堆的问题，客户端虚拟机用于短期运行程序，而服务器端虚拟机用于长期运行程序。一般来说，用服务器虚拟机来运行JBOSS AS更为可取。
在bin/run.bat(Windows)文件或bin/run.conf（Linux)文件里编辑JAVA_OPTS设置来选择需要的虚拟机。在默认情况下，两个脚本都设置使用服务器虚拟机，在run.bat里设置的一个示例如***意-server选项必须是命令行里的第一个选项)
set JAVA_OPTS =-server %JAVA_HOME%....
JAVA堆
在java应用程序分配对象的同时，虚拟机会将那些对象存放在一个由虚拟机分配的堆里。在应用程序不再需要该对象并删除该对象的所有引用后，该对象将不能被访问。垃圾回收一般发生在虚拟机分配新的对象而无足够空间时。
| 永久代 | 年老代 | 年轻代（eden space) |
年轻代（young generation）由eden Space(所有新建对象创建于此）和两个剩余空间（to space和from space）组成。永久空间保存类对象（包括java.lang.Class类实例和方法实例）
| 参数 | 描述 | 注释 |
| -Xms<size> | 设置堆的最小值 | 在生产阶段，最小和最大堆值设为相同的值 |
| -Xmx<size> | 设置堆的最大值 | |
| -XX:NewSize=<size> | 设置年轻代的最小值 | 在生产阶段，最小和最大年轻代的值设为相同的值 |
| -XX:MaxNewSize=<size> | 设置年轻代的最大值 | |
| -XX:NewRatio=<number> | 设置年轻代和年老代的大小比例。例如数值是2时，年老代将是年轻代大小的2倍 | 使用NewSize/MaxNewSize参数或NewRatio参数，但不要两个参数都使用 |
| -XX:SurvivorRatio=<number> | 设置eden space和剩余空间的大小比例。例如，剩余空间比例为8时，eden space是任一剩余空间大小的8倍。 | 基于年轻代大小改变比例，比例为8适用于小的年轻代（如10M),32适用于大的年轻代（如100MB) |
| -XX:+UseTLAB | 在eden space里给应用程序的每一个线程提供它自己的分配区域（线程本地分配块TLAB).注意它是一个布尔型选项，用plus(+)可以启动它，用minus(-)（-XX:-UseTLAB)可以禁用它 | |
| -XX:TLABSize=<size> | 每一个TLAB的大小 | 确保年轻代空间足够为应用程序里的每一个线程保存所有的TLAB。应该分别使用64KB、128KB和256Kb进行尝试。 |
| -XX:MaxTenuringThreshold=<number> | 表示一个对象在被自动放置于年老代之前必须存活的次要回收数量 | 一般应该使用的值是32 |
| -XX:MaxPermSize | 设置永久代的大小 | 在用完空间后再设置永久代 |
建议：
1. 将堆的最大值和最小值设置为相同的值，如果这个值不同，jvm会花一定时间运行应用程序来确定是否应该在垃圾回收后调整大小。
2. 将年轻代大小的最大值和最小值设置为相同的值，而且年轻代的大小应该为堆大小的1/4～1/3.
示例：
可以通过设置JAVA_OPTS环境变量或修改运行脚本文件里的JAVA_OPTS行来为JBoss AS设置这些值。如将run.bat脚本里的JAVA_OPTS行的值修改为堆为1200M,年轻代为400M，并将剩余空间的大小设置为eden space大小的1/32.此外，每个线程会得到它自己的分配块，为64KB。
set JAVA_OPTS=%JAVA_OPTS% -Xms1200m -Xmx1200m -XX:NewSize=400M -XX:NewSize=400M -XX:SurvivorRation=32
-XX:+UseTLAB -XX:TALBSize = 64k
上一篇： JVM 性能调优
下一篇： python — 获取网页图片资源