相关疑难解决方法(0)

有没有人有使用Java中12 GB或更高的大堆的经验？

• GC是否使程序无法使用？
• 您使用什么GC参数？
• 哪个JVM,Sun或BEA更适合这个？
• 哪种平台,Linux或Windows,在这种情况下表现更好？
• 在Windows的情况下,在如此高内存负载下64位Vista和XP之间是否存在任何性能差异？

在Tomcat 7/Java 7上运行几个(大约15个)Java EE-ish Web应用程序(Hibernate 4 + Spring + Quartz + JSF + Facelets + Richfaces)的实例时,我遇到了一个奇怪但严重的问题.

系统运行得很好,但是在大量不同的时间之后,应用程序的所有实例同时突然受到响应时间上升的影响.基本上应用程序仍然有效,但响应时间大约高出三倍.

这是两个图表,显示两个示例实例的两个特定的短工作流/操作(登录,研讨会的访问列表,ajax刷新此列表,注销;下面的行只是ajax刷新的请求时间)的响应时间申请:

正如您所看到的,应用程序的两个实例在同一时间"爆炸"并保持缓慢.重新启动服务器后,一切都恢复正常.应用程序的所有实例同时"爆炸".

我们将会话数据存储到数据库并将其用于群集.我们检查了会话大小和数量,两者都相当低(这意味着在其他服务器上我们有时会有更大和更多的会话).群集中的另一个Tomcat通常会保持快几个小时,在这个随机时间之后它也会"死".我们使用jconsole检查堆大小,主堆保持在2.5到1 GB大小之间,db连接池基本上充满了空闲连接,以及线程池.最大堆大小为5 GB,还有很多可用的perm gen空间.负荷不是特别高; 主CPU只有大约5%的负载.服务器不交换.它也没有硬件问题,因为我们将应用程序另外部署到VM,其中问题保持不变.

我不知道在哪里看,我没有想法.有人知道在哪里看？

2013-02-21更新:新数据!

我在应用程序中添加了两个时序跟踪.至于测量:监视系统调用执行两个任务的servlet,测量服务器上每个任务的执行时间,并写入作为响应的时间.监视系统记录这些值.

我有几个有趣的新事实:应用程序的热重新部署导致当前Tomcat上的这个单个实例疯狂.这似乎也会影响原始CPU计算性能(见下文).这种个别情境爆炸不同于随机发生的整体情境爆炸.

现在有些数据:

首先是个别行:

1. 浅蓝色是在客户端上测量的小工作流程的总执行时间(详见上文)
2. 红色是浅蓝色的"一部分",是在客户端上测量的执行该工作流程的特殊步骤所花费的时间
3. 深蓝色是在应用程序中测量的,包括从DB通过Hibernate读取实体列表并迭代该列表,获取惰性集合和惰性实体.
4. Green是使用浮点和整数运算的小型CPU基准测试.据我所见,没有对象分配,所以没有垃圾.

现在针对爆炸的各个阶段:我用三个黑点标记每个图像.第一个是或多或少只有一个应用实例的"小"爆炸 - 在Inst1中它跳跃(特别是在红线中可见),而Inst2低于或多或少保持平静.

在这次小爆炸之后,"大爆炸"发生,并且该Tomcat上的所有应用程序实例都爆炸(第二个点).请注意,此爆炸会影响所有高级操作(请求处理,数据库访问),但不会影响 CPU基准测试.它在两个系统中保持低水平.

之后,我通过触摸context.xml文件热重新部署了Inst1.正如我之前所说的那样,这个例子现在从爆炸变为完全被破坏(浅蓝色线在图表之外 - 大约是18秒).请注意a)这种重新部署根本不会影响Inst2,以及b)Inst1的原始数据库访问如何也不会受到影响 - 但CPU突然变得越来越慢!.我说这很疯狂.

更新更新 Tomcat的防漏监听器在取消部署应用程序时不会抱怨陈旧的ThreadLocals或Threads.显然有一些清理问题(我认为这与大爆炸没有直接关系),但是Tomcat对我没有任何暗示.

2013-02-25更新:应用程序环境和Quartz计划

应用程序环境不是很复杂.除了网络组件(我不太了解),基本上有一个应用服务器(Linux)和两个数据库服务器(MySQL 5和MSSQL 2008).主要负载在MSSQL服务器上,另一个仅用作存储会话的位置.

应用程序服务器运行Apache作为两个Tomcats之间的负载平衡器.因此,我们在同一硬件上运行两个JVM(两个Tomcat 实例).我们使用此配置实际上不平衡负载,因为应用程序服务器能够正常运行应用程序(它已经多年来一直运行),但是可以在不停机的情况下实现小型应用程序更新.有问题的Web应用程序作为不同客户的单独上下文部署,每个Tomcat大约15个上下文.(我认为在我的帖子中混淆了"实例"和"背景" - 在办公室里,他们经常被同义词使用,我们通常神奇地知道同事在谈论什么.我的不好,我真的很抱歉.)

用更好的措辞来澄清情况:我发布的图表显示了同一JVM上同一应用程序的两个不同上下文的响应时间.大爆炸会影响一个JVM上的所有上下文但不会发生在另一个JVM上(Tomcats爆炸的顺序是随机的btw).在热重新部署之后,一个Tomcat实例上的一个上下文变得疯狂(带有所有有趣的副作用,就像上下文中看似较慢的CPU一样).

系统的总负载相当低.它是一个内部核心业务相关软件,同时拥有约30个活跃用户.特定于应用程序的请求(服务器触摸)目前大约是每分钟130个.单个请求的数量很少,但请求本身通常需要数百个选择到数据库,因此它们相当昂贵.但通常一切都完全可以接受.该应用程序也不会创建大型无限缓存 - 某些查找数据会被缓存,但只能在很短的时间内完成.

上面我写道,能够运行应用程序的服务器已经好几年了.我知道找到问题的最佳方法是找出第一次出现问题的确切时间,并查看在此时间范围内(在应用程序本身,相关库或基础架构中)已更改的内容,但问题是我们不知道问题何时首次发生.让我们称之为次优(在缺席的意义上)应用程序监控...: - /

我们排除了一些方面,但是在过去几个月中应用程序已经多次更新,因此我们不能简单地部署旧版本.非功能更改的最大更新是从JSP切换到Facelets.但仍然,"某些东西"必然是所有问题的原因,但我不知道为什么Facelets会影响纯数据库查询时间.

石英

至于Quartz时间表:总共有8个工作岗位.它们中的大多数每天只运行一次,并且与大容量数据同步有关(绝对不像"大数据大"那样"大";它只是比平常用户通过他日常工作所看到的更多).然而,这些工作当然是在夜间运行,问题发生在白天.我在这里省略了一份详细的工作清单(如果有益,我可以提供更多详细信息).在过去的几个月里,工作的源代码没有被改变.我已经检查了爆炸是否与工作一致 - 但结果最多也是不确定的.我实际上说他们没有对齐,但由于每分钟都有几个工作,我还不能排除它.在我看来,每分钟运行的实际工作相当轻,他们通常会检查数据是否可用(在不同的来源,数据库,外部系统,电子邮件帐户),如果是,请将其写入数据库或将其推送到另一个系统.

但是,我目前正在启用单个作业执行的记录,以便我可以准确地看到每个单个作业执行的开始和结束时间戳.也许这提供了更多的见解.

2013-02-28更新:JSF阶段和时间

我手动向应用程序添加了一个JSF phae监听器.我执行了一个示例调用(ajax刷新),这就是我所拥有的(左:正常运行Tomcat实例,右:Big Bang之后的Tomcat实例 - 几乎同时从两个Tomcats中获取数字并且以毫秒为单位): …

我们在其中一个应用服务器上看到了一个有趣(但非常严重)的问题:在某个时间点,运行我们的Web应用程序的JVM的CPU使用率开始上升并持续上升,直到应用程序最终减速到爬行.解决此问题的唯一方法是重新启动应用程序服务器软件.

• 应用服务器:Spring tc Server(因为服务器托管在别处,我目前还不知道确切的版本)
• 应用程序:相对标准的Spring 3 Web应用程序(我们确实使用in-JVM EHCache)

这让我想到一个简单的问题; 我们可以做些什么来解决这个问题？

我考虑过使用VisualVM(或其他一些JVM监控工具),但他们能做的最好 - 在这种特殊情况下 - 给我一个线程转储,它仍然不会告诉我是什么占用了所有的CPU时间(除非我我错过了什么.