Skip to main content
A
Anonymous
August 8, 2007
Question

ColdFusion MX 6.1 and IIS suddently become unresponsive

  • August 8, 2007
  • 7 replies
  • 1168 views

We have a ColdFusion MX 6.1 server ( updated since this March with cfmx_61_updater_windows.exe, version 6,1,0,83762
) on Windows Server 2003 SP2. It runs well hosting our webGIS applications till recently. 1-3 times a day or once in 1-5 days, the server is hanging and not responsive to any web application requests. At the time, I could ping the server, but not be able to access any web folder or application: the connection was simply hanging on there. A restart of IIS doesn't help. But retarting the CF server fixes the problem. It seems to be a memory leakage problem and I did notice when it hung, that the CF server (jrun.exe) used about 590mb memory, which could be out of the max set up for JVM Heap Size.

I applied the hot fix hf59763_611.jar ( http://kb.adobe.com/selfservice/viewContent.do?externalId=1ea55f4a&sliceId=1 ), but it didn't fix our problem. No useful error info is available from all log files.

So, any clue for fixing this type of problem? Any specific hot fixes I should applied on top of the MX 6.1 updater? I have increased the max JVM Heap Size from 512 to 640 Mb today and will see if this helps.

Any help is much appreciated.
    This topic has been closed for replies.

    7 replies

    A
    Anonymous
    August 14, 2007

    Thanks Prabhu again. I have forarded your respones to the application developers in hopes that they will review the codes and check with the users to see if sloppy codes exist or proper session closing codes are in place.

    So far since the increase of the max heap size last week, the server has not yet encountered the same hanging problem. I hope this workaround would be good enough for a while.

    Thanks
    A
    Anonymous
    August 14, 2007
    save this content in a separate CFM and execute it. It will give you the total no. of sessions available for an application
    A
    Anonymous
    August 9, 2007

    Thanks Prabhu and Ian Skinner again for your notes.

    Sorry, I am not familiar to the formula prescribed by SUN to allocate min & max heap sizes. The server is with 3.6 Ghz dual processors, 2 gb physical memory and 3.8gb virtaul memory. What is 'DefaultInitialRAMFraction'? My current setup for CF server is 1024 Mb max heap size, and blank for min heap size (default). When the problem happened, the max heap size was 512 Mb (default) and I have increased it to 1024 Mb yesterday. Since then, the server has been running well without the problem for a day. I hope the increased max heap size can at least delay the problem as Skinner said. If the used memory can be released timely before the total usage is upto the max heap size, the increased max heap size may reduce or even eliminate the chances of resulting in the server hanging problem.

    I don't see how could I "Use Agressive GC in CFMX administrator "? could you please instruct me on this?

    I don't see much CPU usage on the server from the Task manager, under 5% most of times.

    Do you think that using a specific Application Pool for a memory intensive web application could help solve the problem? This application pool can be configured with a work-process and memory recycling frequency?

    In fact, during the last 2-3 weeks when the problem started happening, there have been less users of the applications on that server because of the union strike in our city. However, our users in the last 2-3 weeks are different: they are managers and few, who may not be trained well in properly using the applications.

    Could the CF server be damaged to some extent? is it worth trying to re-install the software?

    Many thanks again.

    A
    Anonymous
    August 11, 2007
    Have a look over this excellent thread posted by robisen . http://www.robisen.com/index.cfm?mode=entry&entry=FD4BE2FC-55DC-F2B1-FED0717CC1C7E0AF

    In your previous message you posted that the application was handled by the users those who are not well trained. Please check with your application whether memory ( session & objects ) is released when the user closes the window abruptly without logging off. If you didn't handle this scenario in your code, the memory used for session & memory used in object creation will be remained as such. Please have a look over this and reply me back. This could be a possible reason of excessive memory used by your CFMX server.

    By the way the DefaultInitialRAMFraction is 64 MB, you can have a MAX heap size greater than 1 GB, please refer SUN website for more details in using Memory size more than 1 GB.

    N
    Newsgroup_User
    Inspiring
    August 9, 2007
    csmli wrote:
    > Thanks Ian Skinner for your quick response.
    >
    > Note that our applications have been running well in production for a while
    > (at least 4-5 months after the MX 6.1 updater install), and we didn't change
    > anything either on server or on applications recently. So why this problem
    > didn't happen before or in development, but just happened now? maybe the
    > specific functions of an application causing the problem have never been fully
    > tested before?
    >

    Or load has increased.

    Maybe earlier the application was not being used enough - fast enough to
    full up memory before old data was cleaned up. But now it is being used
    more often so that the memory is filled before old data is removed.
    A
    Anonymous
    August 9, 2007

    Prabhu, the JDK version is 1.4.2_11 (home: D:\j2sdk1.4.2_11\jre ) from Sun Microsystems Inc. As I said the CF MX 6.1 updater was installed and the hot fix installed too, so the version is: 6,1,0,hf59763_611. Do you think there are big differences between 1.4.2_11 and j2sdk1.4.2_13? should I install j2sdk1.4.2_13 or even a newer one?
    A
    Anonymous
    August 9, 2007
    I'm not sure about the performance of 1.4.2_11, I do use 1.4.2_13b which is the last version of 1.4 series. Please find the easiest formula prescribed by SUN to allocate min & max heap sizes.

    minimum heap size = memory / DefaultInitialRAMFraction
    maximum heap size = MINIMUM(memory / DefaultMaxRAMFraction, 1GB)

    If you feel the 1.4.2_11 doesn't have much memory leak, then you have to concentrate with Garbage Collector. Poor performance of GC will also leads to Java.lang.Out.of.Memory Error. Use Agressive GC in CFMX administrator will help in some extent.

    By the way , How the server performing after the heap size to 640 MB.

    The thing is GC will fire only when the CPU is less utilized, literally you cannot imagine a scenario of production server CPU is utilized less.
    A
    Anonymous
    August 9, 2007
    Could you share the information about your JDK version? Because JVM which is having a memory leak problem would be a cause for that. I had witnessed this issues couple of times with my application. Whenever your application requires bulk memory to process a request, you can witness the jrun size would goes on increasing but it never come down even after processing the request.

    As Ian Skinner said, an extensive review in your code would seal all the issues.

    Apart from sloppy queries, objects which are created and not destroyed will keep on occupying some space in the JVM could be a cause. Now I'm using j2sdk1.4.2_13, which reduces the memory leak to the MAX when compared to my earlier version jdk1.3.

    I would suggest you to use the same if you using any other version of JAVA JDK. There are some other JVM’s like JRockit etc… also doing fine in this memory leak issue.

    This scenario didn't occur so far because you might have missed out some scenarios (like regression) testing.

    Respond me back with your results.
    A
    Anonymous
    August 9, 2007
    Thanks Ian Skinner for your quick response.

    Note that our applications have been running well in production for a while (at least 4-5 months after the MX 6.1 updater install), and we didn't change anything either on server or on applications recently. So why this problem didn't happen before or in development, but just happened now? maybe the specific functions of an application causing the problem have never been fully tested before?
    N
    Newsgroup_User
    Inspiring
    August 8, 2007
    Applications that make greedy use of memory could be a problem.
    Increasing available memory only delays the problem if the root cause is
    not rooted out and resolved.

    One may need to make an extensive review of code and look for excessive
    and hopefully unnecessary memory using code. Sloppy queries can often
    be a source of this type of problem.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices