Exit
  • Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
  • 한국 커뮤니티
0

ColdFusion 8.0.1 – server stability and memory usage issue

New Here ,
Feb 02, 2010 Feb 02, 2010

A few questions in this one:

The following is a log of a recurring issue with our ColdFusion 8 Standard server.

The JRun server is currently crashing every other day with the active thread error (error 1).

If the ColdFusion service is not restarted the system will then proceed to run out of memory (error 2) despite Windows still having 0.5 – 1GB to spare

A couple of things worth noting:

  • The server normally runs with a thread count of 170 – 190
  • When a crash is in progress this jumps to > 400
  • There doesn’t appear to be a specific script or schedule to the crashes
  • When tweaking the JVM Config attempts to assign more than 1024MB of heap space result in failure to start JRun

Preventative action

  • We’ve switched the server to use Oracle’s JRockit JVM due to the monitoring tools available with this VM
  • We’ve tuned the heap to use 1024MB static heap size with a 100M nursery (see VM Config below)
  • We’re using an aggressively tuned GC (see VM Config below)

Questions

  • Why won’t the JVM address more than 1024MB of RAM? Is this a limitation of 32 bit Windows / Java?
  • Why doesn’t the GC handle the thread count before it gets out of hand?
  • Is this expected from a 32 bit server once load reaches a certain level?
  • Is there any way to identify the CF scripts that are causing the thread count to climb?
  • Would switching to 64bit OS address these issues?

Answers

  • On a postcard please …

(More info, configs, log snippets etc is available from the original blog post at http://blog.rubicon.je/ )

961
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Deleted User
Feb 12, 2010 Feb 12, 2010

Questions

  • Why won’t the JVM address more  than 1024MB of RAM? Is this a limitation of 32 bit Windows / Java?
  • Why  doesn’t the GC handle the thread count before it gets out of hand?

  • Is  there any way to identify the CF scripts that are causing the thread  count to climb?   
  • Would switching to 64bit OS address these  issues?

As said ealier, 32 bit JVMs can only address 1.5-1.8GB of memory.

GC is only going to clean up old/dead threads.  If you have threads that are waiting for something else (like, say

...
Translate
Advisor ,
Feb 02, 2010 Feb 02, 2010

There is a max size JVM heap size of 1.8 GB on 32 bit servers.

http://go.adobe.com/kb/ts_tn_19359_en-us

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Feb 12, 2010 Feb 12, 2010

Questions

  • Why won’t the JVM address more  than 1024MB of RAM? Is this a limitation of 32 bit Windows / Java?
  • Why  doesn’t the GC handle the thread count before it gets out of hand?

  • Is  there any way to identify the CF scripts that are causing the thread  count to climb?   
  • Would switching to 64bit OS address these  issues?

As said ealier, 32 bit JVMs can only address 1.5-1.8GB of memory.

GC is only going to clean up old/dead threads.  If you have threads that are waiting for something else (like, say, a DB server) then it won't help you.

Fusion Reactor!

Switching to a 64 bit OS, with a 64 bit version of CF (you'll need CF9 to go standard on 64 bit) and a 64 bit JVM will go a long way.  But if you're code isn't configured to scale correctly, you'll fill the 64 bit version up too.

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Feb 12, 2010 Feb 12, 2010
LATEST

Thanks,

we've provisioned a 64bit CF8 enterprise server and are in the process of migrating some of our larger sites over.

Hopefully this will solve the issue in the short term and buy enough time to refactor the codebase to be more effecient

Rob

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources