JBoss AS 7 性能调优

supreme26

贡献于2014-03-24

字数:10614 关键词: JBoss 应用服务器

JBoss AS 7性能调优 调整JBoss应用服务器 虽然许多架构师和软件工程师同意,约70-80%的应用程序的性能取决于应用程序本身如何编码配置不当的服务器环境可以影响你的用户体验显着,最终,在您的应用价值。 少量的配置元素,它可以影响你的服务器性能相当多,但是,他们中的一些值得特别注意: •JVM调优 应用服务器资源池 •记录 •缓存数据   让我们来看看每个元素详细 JVM调优 在JBoss AS 7运行在Java虚拟机(JVM),因此,它是自然的,可以提供更好的性能与JVM参数的正确配置。 经过多年的发展,实际上改变了每个版本的Java JVM调优。JVM是自J2SE 5.0版的,能够提供一些默认的配置(“人类工效学”),这是与您的环境相一致。然而,更明智的选择提供人机工程学并不总是最优,并没有一个明确的用户设置,表现低于预期。 基本上,JVM调优过程可以分为以下步骤: •选择一个正确的JVM堆大小。这可分为设置一个适当的初始堆大小(XMS)和最大堆大小(-Xmx)使用。 选择正确的垃圾收集算法。 让我们来看看详细的两个元素。 选择正确的JVM堆大小 创建Java对象在堆,每堆分为三个部分或几代人为了在Java的垃圾收集。这些被称为新一代年轻一代,终身或老一代,常驻面积的堆 被进一步划分为三个部分被称为伊甸空间,幸存者1,幸存者2空间。当一个对象被创建在堆中,它被创建新一代伊甸园空间内,如果对象生存在其后的小型垃圾收集,它被移动到幸存者1,然后幸存者2之前,主要的垃圾收集感动, 常驻代堆的堆或彼尔姆地区有些特殊,它是用来存储相关的元数据在JVM中的类和方法,它也承载JVM所提供的字符串池中,为了调整旧的或终身代的对象。JVM,你应该选择一个正确的比例关系(对象最初放置在实例化之后)和年轻一代的终身代(旧的生活代移动)。 对于大多数应用中, 可以通过正确的比例之间的年轻一代之间的1/3到1/2。相应的最大堆大小不等的终身代的峰值负载测试您的应用程序一致的时间。一旦你已经确定你的应用程序所要求的内存峰值,你可以允许一个额外的25-40%的额外最大堆大小,取决于你的应用程序的性质, 至于它涉及,初始堆大小,一个好的规则拇指是将其设置为最大堆大小一样。这增加了可预测性和避免了需要分配内存来扩展堆。这是特别有用的生产环境,而开发者(谁拥有有限的资源)可能会选择一个更小的初始堆大小。 较小的环境作为一个参考,也为更大的保持这个建议配置: java的为-Xmx1024M Xms1024m-XX:MaxNewSize =448米-XX:NewSize =448米-XX:SurvivorRatio可= 6  java-Xmx2048m以的Xms2048m-XX:MaxNewSize =896米-XX:NewSize =896米-XX:SurvivorRatio可= 6 调优垃圾收集器 垃圾收集是Java虚拟机提供了一种机制,获垃圾收集的对象,这是回收的堆空间 对象变得符合垃圾收集或GC,如果它是不可达的任何活动线程或任何静态引用。换句话说,你可以说,一个物体变得符合垃圾收集的所有引用空, 选择正确的垃圾收集算法是一个关键的(但经常被忽视的)因素起着重要的作用,在到达您的服务级别要求。有几个垃圾收集器可作为: •     串行器(-XX:+ UseSerialGC):使用一个单独的线程停止其他JVM线程执行垃圾收集器。此收集适合较小的应用程序,我们不建议使用它的企业应用并行收集器(-XX:+ UseParallelGC):并行执行次要回收,因为J2SE 5.0还可以执行并行(-XX主要收藏:+ UseParallelOldGC)的。此收集适合于多处理器的机器和应用,需要高吞吐量。这也是一个建议选择应用产生一个支离破碎的Java堆,大尺寸的物体分配在不同的时间表,并发收集器(-XX:+ UseConcMarkSweepGC启用并发标记-清除收集器),它执行的大部分工作,同时使用一个单一的垃圾收集器线程运行与应用线程同时。它适合快速的处理器的机器和应用具有严格的服务水平协议。它可以是最好的选择,也为应用,使用长寿命的对象大集现场的HttpSessions。 新的G1收藏家 在Java 7的主要增强功能之一是新的G1(“垃圾”)低延迟计划取代CMS在HotSpot JVM中的垃圾收集。这是一个服务器式集热器,有针对性地在多处理器机器上大量的内存。 G1的收集器是一个出发从早期的收藏家,其中有一个年轻的老两代之间的物理隔离。用G1,即 使它是代际,有没有两代之间的物理分离。此收集器的整个空间分割成多个区域,并允许收集的一组区域,而不是空间分割成任意的年轻和老一代 G1集电极的主要特点是: 1。G1采用并行,大多是用在今天的硬件。G1的主要优点是设计以这样一种方式来利用所有可用的CPU,并利用所有CPU的处理能力,以及提高性能并加快垃圾收集。 2。下一步功能,起着关键的作用,增加了垃圾收集处理不同年轻的对象(新创建)和旧的对象(住了一段时间)。G1主要侧重于年轻的对象,因为他们可以穿越旧物时,可回收。 3。     堆压实做是为了消除碎片问题。因为G1契约,因为它的收益,从本质上讲,它复制的对象,从一个区域的堆。因此,由于压实,不会遇到CMS碎片问题。总是会有地区的连续空闲空间分配,使G1具有一致的,随着时间的推移暂停。 内容管理系统相比,G1集电极也更容易使用,因为它有一个订单中的多个交换机,因此调谐VM是简单。G1已经呈现在JDK 7中,截至目前,可以尝试。为了使用G1,需要通过这两个开关:XX:+ UnlockExperimentalVMOptions的-XX:+ UseG1GC 使用大内存页 另一种的JVM优化您的应用程序可以得到实实在在的好处是面积大内存页的使用。大内存页是现代的CPU,允许在2-4 MB块,而不是标准的4KB内存饥饿的应用程序分配内存的一个特点。与Java SE 5.0开始,要求大内存页是一个跨平台的标志:-XX:+ UseLargePages(在默认情况下,对于Solaris,默认情况下关闭Windows和Linux)。    大页面支持的目标是优化处理器转换后备缓冲器(TLB)。转换后备缓冲器是一个网页翻译缓存,存放最近使用的虚拟地址到物理地址翻译。TLB系统是一种稀缺资源。TLB缺失可能是昂贵的处理器必须从层次的页表,这可能需要访问多个存储器然后读取。通过使用更大的页面尺寸,一个单一的TLB项可以代表大内存范围。会有压力较小(TLB)和内存密集型应用程序可能有更好的表现。 大内存页有64位JVM。(红帽企业Linux确实让你分配大页面上的32位操作系统,但启动JVM时,你会得到一个非法参数) Sun的JVM,以及OpenJDK的,需要以下的选项,通过在命令行上,使用大页面:-XX:+ UseLargePages 应用服务器资源池的 应用服务器池的使用,因为首次发布的任何应用服务器为手段,以它们所包含的资源设置边界。资源池提供了几个好处,如:•改进性能:您可以重新分配资源密集型的对象,如数据库连接,而不是创建和销毁他们的每一次改进安全:授予数量有限的资源,你防止掠夺的服务器资源,从应用,最终可能会导致的AS服务中断。 7 JBoss AS中使用多个资源池来管理不同种类的服务。应用服务器附带了一个默认的配置所有资源池的简单应用这可能是刚刚好。如果您正计划写关键任务的应用程序,但是,你需要找到适当数量的资源被分配到池。 特别是在我们将讨论以下池中的资源,性能调整,最终发挥了重要作用:EJB池使用无状态的EJB 和MDB  数据库连接池的Web服务器的线程池      在写作的时候,应用服务器是不是准备生产,我们已经提到的所有子系统的性能指标。虽然,这将是最好通过管理界面来监控应用程序服务器池,你仍然可以使用一些其他的工具的应用服务器池或一看,里面最小的示例应用程序。这就是我们将在接下来的章节中。(然而我们更新这篇文章,尽快性能调整指标,所以回来看望我们的到来!)   第2页(共6页) 优化数据库连接池 建立一个DBMS的JDBC连接可以是相当缓慢的。如果你的应用程序需要被反复打开和关闭数据库连接,这可以成为一个显着的性能问题。JBoss AS中的数据源的连接池提供了一个有效的解决这个问题。 什么是重要的是要强调的是,当客户端关闭连接从一个数据源,连接返回到池中,并成为供其他客户端,因此连接本身没有关闭。打开和关闭连接池的成本可以测量纳秒,所以它在性能方面无关。 在下面的例子中,我们加强​​第3章中暴露的数据源配置,配置企业服务的一些连接池的配置: 01. 03. 04.jdbc:mysql://localhost:3306/MyDB 05. 06.mysql 07. 08.10 09.30 10.true 11. 12. 13.30000 14.5 15. 16. 在这里,我们配置的初始池容量10连接,它可以成长到30。正如你可以看到从下面的MySQL管理控制台, 您设置预填充的元素设置为true时,应用服务器尝试启动预填充连接池。这可以生产出性能损失,特别是如果你的连接是昂贵的收购。 如果应用程序服务器是不能够为更多的连接,因为他们都在使用,那么它会等待阻塞超时米利斯抛出异常之前到客户端。 与此同时,连接已闲置一些分钟超过闲置超时参数分钟,他们被迫返回到池中。 调节池的大小 要确定适当的大小,你需要监视你的连接使用。这可以通过几种方式。如果你有机会到命令行界面,你可以监视你的数据源的运行时性能。这里是我们的示例应用程序交付第4章中的示例输出: [standalone@localhost:9999 /]/subsystem=datasources/data-source="java:/MySqlDS":read-resource(include-runtime=true) { "outcome" => "success", "result" => { "ActiveCount" => "10", "AvailableCount" => "29", "AverageBlockingTime" => "0", "AverageCreationTime" => "56", "CreatedCount" => "10", "DestroyedCount" => "0", "MaxCreationTime" => "320", "MaxUsedCount" => "5", "MaxWaitCount" => "0", "MaxWaitTime" => "1", . . . . } } 此命令的输出然而,相当冗长的输出开始时位于最有趣的属性:特别是活动核心属性,它显示当前处于活动状态的连接和MaxUsedCount的量,这是由应用程序所用的连接的峰值。 请注意:如果你是预填池,前面一节中所示,这些连接都将导致活动。这可能是误导,导致你的假设他们实际上是忙碌的,   如果你是不能够使用CLI或只是有一些有效的替代,你想用好你的DBA认证:第一个也是最明显的是监控数据库会话。下表显示了一些有用的命令,它可以用来在不同的数据库中记录的活动数据库连接: Database Command / Table Oracle Query the V$SESSION view MySQL Use the command SHOW FULL PROCESSLIST Postgre-SQL Query the PG_STAT_ACTIVITY table 另一种选择是使用P6Spy的工具,如作为一个JDBC代理驱动的。(我博客上一篇关于这里)。 一旦你找到连接您的应用程序所使用的高峰期,刚刚成立的最大的高出至少25-30%。不要有关设置最大过高的关注,因为如果你不需要有很多的连接,池将自动缩小,只要你已经设置了空闲超时分钟。 另一方面,你的服务器日志仍然一个非常宝贵的帮助检查,如果你的池运行陷入困境。例如,如果你开始在你的服务器日志中看到这个异常,有强烈的线索,你需要看看你的连接池:21:57:57,781 ERROR [0](HTTP执行人主题- 7)所引起的: javax.resource.ResourceException:IJ000655:管理连接在配置阻塞超时(30000毫秒)21:57:57,782 ERROR [STDERR](HTTP执行人线程- 7)org.jboss.jca.core.connectionmanager已。pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection < JBoss的AS 7性能调整 - jboss的记录调整 第5页(共6页)     测井微调 记录是一个重要的活动,每一个应用程序,但是默认的配置一般是适当的发展,但不用于生产环境。 你需要考虑当切换到生产的关键要素是:   1。选择相应的处理程序输出的日志。 选择日志级别,只提供了大量的信息,你需要的,没有别的。 3。选择一个合适你的日志格式 至于它涉及,日志处理程序,在默认配置中,控制台日志记录和文件记录被启用。虽然这可能是罚款的发展,在生产中使用控制台日志是一个昂贵的过程,这会导致大量的非缓冲I / O 虽然一些应用程序可能罚款控制台日志,关闭控制台日志记录和文件处理程序仅仅使用高容量应用的好处。 为了消除控制台记录,你可以简单地评论它的处理程序: 2. 3. 4. 5. 6. 7. 下一步是选择正确的日志记录级别。显然,少你登录,I / O将发生,更好的整体应用。默认配置使用的“INFO”级别的根logger。你可以考虑提高到一个更高的门槛像“WARN”或(使用细粒方法),改变了单一的日志记录类别 1. 2. 3. 在这个例子中,我们只是提出“WARN”,这将产生一个更简洁的信息从休眠org.hibernate包的日志级别, 最后,还可以使用你的日志模式影响您的应用程序的性能。例如,让我们的默认模式的格式,这是: 1. 日志记录模式的详细说明,可以发现在第2章的第控制台处理程序。从这个基本格式,用尽可能少增加的标志%L,则可以大大提高你的日志的详细程度,打印行号和排放日志的类: 1. 这是控制台输出,一旦服务器配置已重载:虽然这个信息是非常有用的发展,它会导致移植在生产时,一个巨大的负担。其他标志,可以记录性能有负面影响%C(打印出的主叫类信息),%M(发出日志输出的方法)和%F(发出日志请求输出的文件名 ​​)。 JBoss的AS 7性能调整 - 优化Web服务器的线程池 第4页(共6页)   优化Web服务器的线程池   有最终影响Web服务器的性能优化方面大集。最重要的因素之一是调整的HTTP连接器的线程池设置,以更紧密地匹配Web请求负载。这是很难做到的,但得到的权利以获得最佳性能是非常重要的。 执行人属性通过引用Web服务器所允许的线程数量: 01. 02.  03. 11.. . . 12. 然后,在线程子系统,你可以定义线程池将使用的数量,以及与其他线程属性(线程子系统的更多细节,请参阅第2章,配置应用程序服务器): 01. 02. 04. 05. 06. 07. 08. 09. 最重要的连接器属性被定义为核心线程和最大线程。设置这些值太低,意味着你可能没有足够的线程来处理所有的请求,在这种情况下,请求必须坐在闲置了一段时间而没有被处理,直到另一个请求线程被释放。值太低也意味着JBoss的Web服务器将无法充分利用您的服务器计算机的硬件。 另一方面,要小心增加这些线程计数盲目之前。通过增加线程数太多,你会: •消耗了良好的内存块 •您的系统将花费太多时间上下文切换 首先,你应该调查,而如果它是个人要求的时间太长的问题。您返回线程池?例如,如果不释放数据库连接,线程堆起来等待获得一个数据库连接,从而使其无法处理其他请求。 在这种情况下,简单地增加更多的线程,将CPU和垃圾收集器引入更大的压力,使事情更糟。你可以发现这样那样的问题,简单地把在您的应用程序中,找出你的web服务器线程阻塞的线程转储。例如,在这张照片中,从JConsole的线程“选项卡,你可以看到一个空闲线程如何应该的样子,看着它的堆栈跟踪: 另一方面,下面的HTTP线程忙于做输入/输出操作,这可能意味着,例如,Web服务器从外部资源中获取数据。以上的快照,也为您提供了一个线索你如何能监控号码Web服务器运行的线程。只需填写较低的TextField的执行人名(HTTP执行人),你将有一个过滤列表中所有的web服务器线程。 JBoss AS 7性能调优的 - TUNING EJB的连接池 第3页(共6页)   TUNING EJB连接池 创建和销毁豆可以是一个昂贵的操作,特别是如果他们获得外部资源。为了减少这种成本,EJB容器创建池豆类,因此,不需要重新初始化每次他们需要的, 无状态的EJB池和MDB池是用来服务他们的客户提供无状态的业务,收购豆从池中时,他们被要求和释放到池中的bean,尽快为他们完成 一个典型的EJB池配置如下所示: 1. 2. 3. 4. 5. 6. 在写AS 7的时候,有只支持最大严格作为一个bean实例池池。 严格的最大池允许您配置一个池的最大上限。在运行时,从池中所有的bean实例都在使用,一个新的bean的调用请求,请求,直到下一个bean实例池块或直到超时(例如收购超时) 。    监测EJB池将很快可以通过CLI,这将有一组最小的操作,检查池指标。然而,建立一个自制的解决方案来监控当前的池大小,不是太复杂:你可以使用方便的EJB3拦截API监测EJB已采取从池中那些已被释放。   在下面的Interceptor,我们只需设置一个单一的EJB辛格尔顿场接触EJB之前和之后,它已经完成了它的工作,从而返回到池中。 package com.packtpub.chapter12; 02.import javax.ejb.EJB; 03.import javax.interceptor.AroundInvoke; 04.import javax.interceptor.InvocationContext; 05.  06.public class EJBInterceptor { 07.@EJB 08.EJBCounter singleton; 09.  10.@AroundInvoke 11.public Object defaultMethod(InvocationContext context) throws 12.Exception{ 13.// Take a bean from the pool 14.singleton.getFromPool(); 15.  16.// Invoke the EJB method 17.Object result = context.proceed(); 18.  19.// Return the bean to the pool 20.singleton.returnToPool(); 21.  22.// Prints out the current pool size 23.singleton.dumpPoolSize(); 24.return result; 25.} 26.} 单身EJB的EJBCounter是它仅仅包含了计数器变量,保存EJB最大池大小。 01.package com.packtpub.chapter12; 02.  03.import javax.ejb.Singleton; 04.@Singleton 05.  06.public class EJBCounter { 07.private int count=20; 08.  09.public void getFromPool() { 10.count--; 11.} 12.public void returnToPool() { 13.count++; 14.} 15.public void dumpPoolSize() { 16.System.out.println("Current pool size is "+count); 17.} 18.} 您可以进一步完善这种方法通过增加从外部来源,如DB或属性文件一个@ PostContruct的加载这个变量的注释。 另一种可行的选择是启动一个CLI脚本收集值达到max-pool-size属性。下面是一个例子: [standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=slsb-strict-max-pool:read-attribute(name="max-pool-size") { "outcome" => "success", "result" => 20 } 拦截器可以应用到您的应用程序可以通过一个简单的注解或宣布他们在ejb-jar.xml配置文件所使用的无状态EJB。例如,这里是如何通过@拦截注释的所有EJB调用拦截: 1 导入javax.ejb.Stateless的 1.import javax.ejb.Stateless; 2.import javax.interceptor.Interceptors; 3.  4.@Stateless 5.@Interceptors(EJBInterceptor.class) 6.public class EJBTest { 7.. . . 8.} 关闭EJB池 虽然这听起来怪异,可以有一些情况下,你不希望你的EJB资源池进行管理,但按需创建。例如,如果你的EJB不需要昂贵的初始化(如获取外部资源),它可以是有利的,在性能方面,避免使用EJB 3个泳池。(例如,在JBoss 5性能调优书,显示所谓的重状态EJB的情况下,甚至可以超越无国籍对口,这主要是由于这样的事实,处理无国籍游泳池是不是一个简单的任务,在性能 方面 关闭EJB池)只需要评论/驱逐到EJB池的bean实例池-ref元素是指: 1. 2. 5. 当然,它强烈建议运行一致的测试床,以证明你的应用可以受益于这样的变化,这将带走任何检查的EJB实例的数量。

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享文档获得金币 ]
0 人已下载

下载文档

相关文档