WebSphere Application Server 6.1 FixPack 21 上的应用程序启动时间较长

发布于 2024-07-26 10:03:12 字数 434 浏览 1 评论 0原文

我发现在从 WAS FixPack15 迁移到 FixPack 21 后,我的应用程序启动时间增长了很长时间。应用程序启动时间是指日志语句之间的时间间隔:

WSVR0200I: 正在启动应用程序

AND

WSVR0221I: 应用程序已启动

此时间间隔是在 FP 15 上不到 10 秒,但在 FP 21 上则为 2 分钟。除了新的修复包之外,没有任何变化。 但是,如果我退回 WAS 实例,然后启动应用程序,则启动时间很短(10 秒)。 但有时,当我不弹回我的 WAS 实例时,我的应用程序在 FP 21 上启动需要 2 分钟,而过去在 FP 15 上启动需要 10 秒。

我想知道你们中是否有人对如何解决此问题有任何指示。

我的操作系统是 Red Hat Enterprise Linux Server 5.1 版 (Tikanga)

I'm seeing that my application startup times have grown long after I've migrated from WAS FixPack15 to FixPack 21. By application startup time, I mean the interval between the log statements :

WSVR0200I: Starting application

AND

WSVR0221I: Application started

This interval was less than 10 sec on FP 15, but it is 2 min on FP 21. Nothing has changed, except for the new fix pack.
However, if I bounce my WAS instance, and then start the application, the start up time was short (10 sec). But on occasions when I don't bounce my WAS instance, my application startup on FP 21 takes 2 min where it used to take 10 sec on FP 15.

I was wondering if any of you have any pointers about how to troubleshoot this issue.

My OS is Red Hat Enterprise Linux Server release 5.1 (Tikanga)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

太阳公公是暖光 2024-08-02 10:03:12

我要做的一件事是通过将日志与较快版本和较慢版本进行比较来计时。 这可以让您将较差的性能缩小到单个组件而不是整个组件。

我过去使用过 21,并没有注意到它变慢,但这表明我在 AIX 和 Windows 上使用它,所以这可能是操作系统问题。

如果您缩小了性能不佳的功能的范围,请将其发布在这里,然后我会再看一下。

问候,

迈克尔。

One thing that I would do is time it by comparing the logs against the faster version and the slower version. This may allow you to narrow the poor performance down to an individual component rather than the entire thing.

I have used 21 in the past and didn't notice it being slower, but that said I was using it on AIX and Windows so it may be an operating system issue.

If you narrow down the poorly performing function post it here and then I will look at it a bit more.

Regards,

Michael.

无声静候 2024-08-02 10:03:12

我从 FP13 转到 FP21,并没有发现我的应用程序有任何放缓,但那是在 Windows 上。

你确定这是你唯一改变的吗?

您的应用程序中是否使用了任何 WebSphere API/代码?

您实际上应用了所有修复包吗? 下载页面是一个真实的视力表,但您必须更新 WebSphere Java SDK。 如果您使用 IHS,则还必须更新 IHS、插件和 SDK。

最后,你说它只是在重新启动应用程序时慢,但在重新启动整个服务器时却慢。 我想知道您的应用程序是否存在 JVM 堆问题。 您运行的堆有多大? 重新启动时是否遇到 GC 问题?

I went from FP13 to FP21 and didn't see any slowdown on my apps, but that was on Windows.

Are you sure that's the only thing you have changed?

Are you using any WebSphere APIs / code in your app?

Did you actually apply all of the fixpacks? The download page is a real eyechart, but you have to update WebSphere and the Java SDK. If you are using IHS, you have to update IHS, the plugins and the SDK there too.

Finally, you say it's only slow when restarting the app, but not when restarting the whole server. I am wondering if there's JVM heap issues with your app. How big of a heap are you running with? Are you seeing GC issues when restarting it?

暮年慕年 2024-08-02 10:03:12

一些想法:

  1. 在 2 分钟暂停期间,每隔 30 秒取出几个 javacore(kill -3 PID),并使用诸如线程和监视器转储分析器之类的工具来比较多个线程转储,以查看线程是否“卡在”某处,进行外部调用或循环。 请参阅 Linux Hang MustGather:http://www-01.ibm。 com/support/docview.wss?uid=swg21115785
  2. 在这 2 分钟的时间间隔内检查 verbosegc(使用垃圾收集和内存可视化工具),看看当时是否有 GC 暂停(2 分钟的暂停意味着您有其他问题)。
  3. 尝试在测试环境中重现该问题。 在那里你可以进行更繁重的调试(例如#4)。
  4. 在启动应用程序之前动态打开*=好吧。 显然,这将对性能造成巨大影响,但除非这是时间问题,否则您应该能够看到时间戳中的任何“间隙”或某种多余的活动。 使用WebSphere Application Server 的跟踪分析器来管理trace.log 文件。

A few ideas:

  1. Take a few javacores (kill -3 PID), 30 seconds apart, during the 2 minute pause and use something like Thread and Monitor Dump analyzer to compare the multiple thread dumps to see if a thread is "stuck" somewhere, making an external call or looping. See the Linux Hang MustGather: http://www-01.ibm.com/support/docview.wss?uid=swg21115785
  2. Check verbosegc during that 2 minute interval (with something like Garbage Collection and Memory Visualizer) to see if there's a GC pause at that time (a 2 minute pause would mean you have other problems).
  3. Try to reproduce the problem in a test environment. There you could do heavier debugging (such as #4).
  4. Dynamically turn on *=all right before starting the application. Obviously this will be a huge performance hit, but unless this is a timing issue, you should be able to see any "gaps" in timestamps or superfluous activity of some sort. Use Trace Analyzer for WebSphere Application Server to manage the trace.log files.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文