Professional Web Applications Themes

Jrun uses all the server memory - Macromedia ColdFusion

Hi im using coldfusion mx 6.1 fully updated. on windows 2003 server with apache 2.46. Every hour or so JRun consumes all the cpu memory and cf application has to restarted manually to free up the cpu again. So I removed all the datasources on the server and left it for the weekend. No problem with jrun. I made a page that counts from 1 to 10000 and displays the date. This was refreshed for an hour or so. Jrun once more consumed all the server cpu. I have trawled through all the technotes, hotfixes, even applied those that seemed ...

  1. #1

    Default Jrun uses all the server memory

    Hi im using coldfusion mx 6.1 fully updated. on windows 2003 server with apache
    2.46. Every hour or so JRun consumes all the cpu memory and cf application has
    to restarted manually to free up the cpu again. So I removed all the
    datasources on the server and left it for the weekend. No problem with jrun. I
    made a page that counts from 1 to 10000 and displays the date. This was
    refreshed for an hour or so. Jrun once more consumed all the server cpu. I
    have trawled through all the technotes, hotfixes, even applied those that
    seemed relevant but the problem remains. Can anybody offer me some guidance on
    this problem. My clients and investors are getting angry with the server
    crashes and slow sites. I am not a coldfusion programmer, and our system
    administrator left last week, leaving me this problem, which he could not fix,
    so keep explanations simple please. thanks for help Danny

    Danny1111x Guest

  2. #2

    Default Jrun uses all the server memory

    Hi im using coldfusion mx 6.1 fully updated. on windows 2003 server with apache
    2.46. Every hour or so JRun consumes all the cpu memory and cf application has
    to restarted manually to free up the cpu again. So I removed all the
    datasources on the server and left it for the weekend. No problem with jrun. I
    made a page that counts from 1 to 10000 and displays the date. This was
    refreshed for an hour or so. Jrun once more consumed all the server cpu. I
    have trawled through all the technotes, hotfixes, even applied those that
    seemed relevant but the problem remains. Can anybody offer me some guidance on
    this problem. My clients and investors are getting angry with the server
    crashes and slow sites. I am not a coldfusion programmer, and our system
    administrator left last week, leaving me this problem, which he could not fix,
    so keep explanations simple please. thanks for help Danny

    Danny1111x Guest

  3. #3

    Default Re: Jrun uses all the server memory

    We need to find out what's happening when the CPU spins. You do that by
    getting a stack trace. -Start CF as a service. -Change the service to 'Allow
    service to interact with Desktop' (checkbox) on the 'Log on' tab of the
    ColdFusion MX windows service. -Restart ColdFusion MX. This should bring up a
    DOS window when the service comes up. Make sure this DOS window has focus.
    - Now, wait until the CPU is spinning or your system is unresponsive or hung
    and click on the DOS window (again so it has focus) and select the keys:
    [Control] + [Pause/Break]. (not Control-C which will kill the process -
    most people are wired to do this so watch it). The output of this action is a
    stack trace showing all running threads. This should be written on the DOS
    Window and in the coldfusion-out.txt. If you do it right, the output should
    look something like this: Full thread dump Java HotSpot(TM) Server VM
    (1.4.2-b28 mixed mode): 'web-1' prio=5 tid=0x28d983c8 nid=0x784 runnable
    [2f0af000..2f0afdbc] at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.ja va:353) - locked
    <0x120170c8> (a java.net.PlainSocketImpl) at
    java.net.ServerSocket.implAccept(ServerSocket.java :448) at
    java.net.ServerSocket.accept(ServerSocket.java:419 ) .. .. .. Send this over
    so we can look at it. It could be any number of things but a stack trace is
    better than 20 questions. Also, since the CPU is spinning, it's really
    important that DOS Window have focus for you to hit [Control] + [Pause/Break].
    It might be very hard to do this and you may only get once chance. Do this
    at least once while the CPU isn't spinning just so you can see how it dumps the
    output. Good luck. Stephen Dupre Macromedia QA

    sdupre Guest

  4. #4

    Default Re: Jrun uses all the server memory

    I've looked over the stack traces. Looks like you have 2 problems: 1)
    Stack trace #1. You have bug 57510. This is a threading issue in the JRun
    server which has a patch. The evidence from the first stack trace: 'jndi-4'
    prio=5 tid=0x009d50b8 nid=0xcd0 in Object.wait() [580f000..580fdc0] at
    java.lang.Object.wait(Native Method) - waiting on <0x13b292a8> (a
    jrunx.scheduler.WorkerThread) at
    jrunx.scheduler.StackMutex.enter(StackMutex.java:4 7) - locked <0x13b292a8> (a
    jrunx.scheduler.WorkerThread) at
    jrun.servlet.network.NetworkService.accept(Network Service.java:356) at
    jrun.naming.NamingNetworkService.accept(NamingNetw orkService.java:115) at
    jrun.naming.NamingNetworkService.createRunnable(Na mingNetworkService.java:141)
    at
    jrunx.scheduler.ThreadPool$DownstreamMetrics.creat eRunnable(ThreadPool.java:315)
    at
    jrunx.scheduler.ThreadPool$ThreadThrottle.createRu nnable(ThreadPool.java:377)
    at
    jrunx.scheduler.ThreadPool$UpstreamMetrics.createR unnable(ThreadPool.java:269)
    at jrunx.scheduler.WorkerThread.run(WorkerThread.java :62) This is one bug
    fixed by this patch. There are also scenarios where the jrpp or web-xx
    threads are missing in the stack trace. This problem is also solved by this
    patch. 2) Stack trace #2. Your registry client purge is running. (this is
    an internal CF operation) Depending on the number of clients in the registry
    and memory on the machine, this could be the CPU spin issue. It could also
    be just fine - you might have just by chance caught it doing the periodic purge
    it does every hour on the hour from system startup. 'scheduler-0' prio=5
    tid=0x04487d90 nid=0xc88 runnable [73af000..73afdc0] at
    coldfusion.tagext.NativeCfx.processRequest(Native Method) at
    coldfusion.tagext.lang.RegistryTag.doStartTag(Regi stryTag.java:90) at
    coldfusion.runtime.ClientScopeServiceImpl.PurgeReg istry(ClientScopeServiceImpl.j
    ava:387) at
    coldfusion.runtime.ClientScopeServiceImpl.PurgeExp iredClients(ClientScopeService
    Impl.java:402) at
    coldfusion.runtime.ClientScopeServiceImpl$ClientSc opePurger.run(ClientScopeServi
    ceImpl.java:532) at coldfusion.scheduling.ThreadPool.run(ThreadPool.ja va:201)
    at coldfusion.scheduling.WorkerThread.run(WorkerThrea d.java:70) Run this
    query to figure out how many records you have in the registry.
    cfgetclients.cfm <cfset start = GetTickCount()> <cftry> <cfregistry
    action='GETALL'
    branch='HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia\Col dFusion\CurrentVersion\Clients
    \' name='q1' type='Key'> <cfcatch
    type='coldfusion.tagext.lang.RegistryException'>no clients <br></cfcatch>
    </cftry> <cfoutput>records: #q1.recordcount#<br></cfoutput>
    <cfoutput>elapsed: #GetTickCount() - start#ms<br></cfoutput> See how many
    records it returns. We changed the code in CF 6.1 Updater 1 to warn the user
    (once) if the # records > 10000. Registry shouldn't be used for high-volume
    sites. You might want to think about moving your client information from
    registry to a SQL Datasource. Stephen Dupre Macromedia QA

    sdupre Guest

  5. #5

    Default Re: Jrun uses all the server memory

    Thanks our server has remained stable for the last 48 hours. Part of the
    problem (besides the first bug which was hotfixed) was indeed the client
    variables. We did in fact have over 300,000 stored in the registry and I
    believe this caused the cycling cpu when coldfusion tried to yse them in
    its hourly garbage cllection routine. I imagine when we installed cf6.1 and the
    warning appeared about having less than 10,000 client variables stored in the
    registry we did not know how many variables we had, or even thought we were
    generating so many so assumed things would work as they always had. The code
    above let us count the variables, perhaps the installer should have counted
    them and warned us what steps we should have taken. Prior to the update this
    site ran fine for several years. We have moved the client variables to a
    database and this seems to have alleviated the stress on our cpu. I am hoping
    as we gather more variables over time this doesn't start the cpu cycling again,
    but for now all seems well. Thanks for the help Danny

    Danny1111x Guest

Similar Threads

  1. JRUN and Windows Virtual Memory
    By mprest in forum Coldfusion Server Administration
    Replies: 3
    Last Post: April 4th, 11:12 PM
  2. Couldn't initialize from remote server, JRun server(s)probably down
    By ecraig in forum Coldfusion Server Administration
    Replies: 0
    Last Post: October 11th, 03:24 AM
  3. Jrun Hangs and Eats Memory
    By Ro6uE in forum Coldfusion Server Administration
    Replies: 1
    Last Post: June 16th, 02:16 PM
  4. 6.1 memory leakage/jrun hogging memory
    By SilentBob'secretfusion in forum Coldfusion - Advanced Techniques
    Replies: 2
    Last Post: May 17th, 01:18 PM
  5. JRun Memory Leak
    By Augusoft in forum Coldfusion Server Administration
    Replies: 3
    Last Post: April 22nd, 07:09 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139