大约在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服务器可能已关闭。
发生了什么事?!
感谢。
答案 0 :(得分:2)
您是否安装了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
答案 1 :(得分:1)
老兄,首先将你的jvm升级到最新版本。我知道我一直这么说,但我不能强调这一点。更新jvm可以修复错误和稳定性的世界。我在此概述了如何执行此操作,并提供了指向cf 8标准的最新版本的链接。
答案 2 :(得分:0)
您可能不想升级JVM。这真的取决于你的应用程序。 cf 8.01的默认JRE是Java 1.6,但是我们发现1.5对我们的应用程序运行效率更高,这对象很重要。垃圾收集机制更有效。
我们让Mike Brunt与我们一起工作,为我们的系统重置活动线程的数量,更改jrun内存分配,并测试各种JVM以查看哪些更适合我们。
最新的JVM应该更好地处理对象繁重的应用程序,但在我们的测试中,我们仍然发现1.5垃圾收集更适合我们的应用程序。
服务器调优是一种艺术,并且需要大量的试验和错误,以使您的环境适合您的应用程序。
(线程太长,无法发表评论)