ColdFusion 8.01 没有响应...如何调查问题所在?

发布于 2024-07-19 05:44:45 字数 608 浏览 5 评论 0原文

大约每隔 1 或 2 个月,我在 Windows 2003 Server + IIS6 上的 32 位 CF8.01(带有累积修补程序 2)会因未知原因而冻结。

任务管理器报告 JRun 使用约 600mb(远低于约 1.2gb 限制)。 CPU 接近 0%。

我检查了 /log,最新更新的日志没有发生任何特别有趣的事情。

一旦我重新启动服务,一切就恢复正常了。

您会采取什么措施来调查问题所在?

我在网上搜索了一下,有人建议这是一种叫做 JRun 死锁的东西。 我怎么知道我是否患有其中一种? 我该如何预防此类问题?

谢谢!

更新: 我查看了 JRun 日志,它有很多以下条目:

无法从远程服务器初始化,JRun 服务器可能已关闭。 返回连接超时的错误页面

jrISAPI 无法初始化 127.0.0.1:xxxxx 的代理

jrISAPI 无法从远程服务器初始化,JRun 服务器可能已关闭。

这是怎么回事!?

谢谢。

About once in 1 or 2 months, my 32bit CF8.01 (with cumulative hot fix 2) on Windows 2003 Server + IIS6 would somehow freeze for an unknown reason.

The Task Manager reported JRun using ~600mb (far from the ~1.2gb limit). CPU is close to 0%.

I checked the /log, and the latest updated log doesn't have anything particularly interesting going on.

Once I restarted the service, things are fine again..

What would you do to investigate what's wrong?

I searched online and someone suggested it is something called a JRun dead-lock. How do I know if I'm having one of those? How do I prevent such problem?

Thanks!

Update:
I looked the at JRun log, and it has a lot of the follow entries:

Couldn't initialize from remote server, JRun server(s) probably down.
returning error page for Connection timed out

jrISAPI could not initialize proxy for 127.0.0.1:xxxxx

jrISAPI Couldn't initialize from remote server, JRun server(s) probably down.

What's going on!?

Thanks.

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

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

发布评论

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

评论(3

維他命╮ 2024-07-26 05:44:46

您是否安装了修补程序

 JRun engineering has fixed the JRun deadlock issue with the hot fix provided below. Follow the instructions to install the hot fix :

   1. Download the hot fix JAR file (3K).
   2. Copy the JAR file into the servers\lib directory (or "servers/lib" on Unix and Linux).
   3. This hot fix is compatible with JRun4 Updater 6 (build 106363) and greater. You can verify your build number by one of the following options:
          * Open the JRun Management Console. Select Settings, then Version, to display the build number.
          * Run the following command at the command prompt:

            On Windows 2000, NT and Win9x:

            cd "{jrun-base-dir}\bin"
            jrun -info

            On Unix and Linux:

            cd $JRUN_HOME/bin
            jrun -info

Have you installed the hotfix?

 JRun engineering has fixed the JRun deadlock issue with the hot fix provided below. Follow the instructions to install the hot fix :

   1. Download the hot fix JAR file (3K).
   2. Copy the JAR file into the servers\lib directory (or "servers/lib" on Unix and Linux).
   3. This hot fix is compatible with JRun4 Updater 6 (build 106363) and greater. You can verify your build number by one of the following options:
          * Open the JRun Management Console. Select Settings, then Version, to display the build number.
          * Run the following command at the command prompt:

            On Windows 2000, NT and Win9x:

            cd "{jrun-base-dir}\bin"
            jrun -info

            On Unix and Linux:

            cd $JRUN_HOME/bin
            jrun -info
不…忘初心 2024-07-26 05:44:46

老兄,先升级你的jvm到最新版本。 我知道我一直这么说,但我怎么强调都不为过。 更新 jvm 可以修复大量错误并保持稳定性。 我在此处概述了如何执行此操作,并提供了 cf 8 标准最新版本的链接。

升级ColdFusion使用的JRE

dude, upgrade your jvm first to the latest version. i know I say this ALL the time, but i can't stress this enough. updating the jvm can fix a world of errors and stability. I outlined how to do this here and provided links to the latest version for cf 8 standard.

Upgrading the JRE used by ColdFusion

一张白纸 2024-07-26 05:44:46

您可能不想升级 JVM。 这实际上取决于您的应用程序。 cf 8.01 的默认 JRE 是 Java 1.6,但我们发现 1.5 对于对象较多的应用程序来说运行效率要高得多。 垃圾收集机制更加高效。

我们让 Mike Brunt 与我们一起解决这个问题,重置系统的活动线程数量,更改 jrun 内存分配,并测试各种 JVM,看看哪个更适合我们。

最新的 JVM 应该能够更好地处理对象较多的应用程序,但在我们的测试中,我们仍然发现 1.5 垃圾收集更适合我们的应用程序。

服务器调优是一门艺术,需要进行大量的试验和错误,才能让您的环境适合您的应用程序。

(帖子太长,无法发表评论)

You may not want to upgrade your JVM. It really depends on your application. The default JRE with cf 8.01 is Java 1.6, but we found that 1.5 operated much more efficiently for our application, which is object heavy. The Garbage Collection mechanisms were more efficient.

We had Mike Brunt come in to work on this with us, resetting the number of active threads for our system, changing the jrun memory allotment, and testing the various JVMs to see which would work better for us.

The latest JVM is supposed to be better at handling object heavy apps, but in our testing we have still found the 1.5 Garbage Collection to be better suited to our application.

Server tuning gets to be a bit of an art, and a lot of trial and error, to get your environment just right for your application.

(Thread was too long for a comment)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文