Inspirations, captions, ideas and notes.

Archive for October, 2007

Still having jrun error…

The setting changes didn’t help, so Nithi has helped to put in the min and max java heap size setting in Coldfusion to 512 and 756.  This seems to have helped stabilise the high CPU hogging by jrun from a constant of 98%-100% to 80%-90%.  However, we feel the cpu utilisation shouldn’t be so high.

To get the version and vendor information from the JRE on our server, we used this link: http://javatester.org/version.html.

Java Version 1.5.0_12 from Sun Microsystems Inc.

Then, from a reference table on the same page, the site informs that our version is the latest version as of Dec 2005!

Next, we looked at the system error logs to see if there’s anything else we can find.  Lots of exceptions and it seems the warnings and exceptions have been there since a long time ago.  To me, its and indication that we need to look into this, but this may not be our immediate concern.

Mark Kruger (http://mkruger.cfwebtools.com/index.cfm?mode=alias&alias=err.log) suggests that log file size could contribute to system slow performance.  He suggests that attributes in jrun.xml can be used to rotate the log files more efficiently, preventing them from getting too big:

<service class="jrunx.logger.LoggerService" name="LoggerService">
...
<attribute name="filename">{jrun.rootdir}/logs/{jrun.server.name}-event.log</attribute>
...
</service>

Can be changed to:

<attribute name="filename">{jrun.rootdir}/logs/{jrun.server.name}-{log.level}.log</attribute>

Only problem is… it doesn’t work for the -err file.

 

Advertisements

Notes while troubleshooting jrun error

The cleanly setup system didn’t solve our problem.  So now, we are exploring the following changes, as recommended by the resources I have listed in my earlier entry:

  • review settings in jrun.xml
  • upgrade jvm

Reviewing jrun.xml

The following extracts show the current settings in our jrun.xml:
<service class="jrun.servlet.http.WebService" name="WebService">
    <attribute name="port">8500</attribute>
    <attribute name="interface">*</attribute>
    <attribute name="deactivated">true</attribute>    
    <attribute name="activeHandlerThreads">200</attribute>
    <attribute name="minHandlerThreads">1</attribute>
    <attribute name="maxHandlerThreads">1000</attribute>
    <attribute name="mapCheck">0</attribute>
    <attribute name="threadWaitTimeout">20</attribute>
    <attribute name="backlog">500</attribute>
    <attribute name="timeout">300</attribute>
  </service>

<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">
    <attribute name="activeHandlerThreads">25</attribute>
    <attribute name="minHandlerThreads">1</attribute>
    <attribute name="maxHandlerThreads">1000</attribute>
    <attribute name="mapCheck">0</attribute>
    <attribute name="threadWaitTimeout">20</attribute>
    <attribute name="backlog">500</attribute>
    <attribute name="deactivated">false</attribute>
    <attribute name="interface">*</attribute>
    <attribute name="port">51010</attribute>
    <attribute name="timeout">300</attribute>
    <!-- set this to false for multi-hosted sites -->
    <attribute name="cacheRealPath">false</attribute>

We have changed the settings as follows:
<service class="jrun.servlet.http.WebService" name="WebService">
    ....
    <attribute name="activeHandlerThreads">100</attribute>
    <attribute name="minHandlerThreads">5</attribute>
    <attribute name="maxHandlerThreads">300</attribute>
    ....
  </service>


<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">
    <attribute name="activeHandlerThreads">100</attribute>
    <attribute name="minHandlerThreads">5</attribute>
    <attribute name="maxHandlerThreads">300</attribute>
    ....
</service>

‘Jrun closed connection’ error on Coldfusion

Our coldfusion server has been getting this error since Thursday and last night, we arranged for a backup server as a fallback should the main one fail. With 2.5 gb in the backup server, we decided to promote it as a main server instead.

This morning, we checked the site again, and found that our problem is still there.

Suggested solutions:

Related information: