I finally found it.
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_18339&sliceId=1
This KB explains thread dumps completely. Once you do your set of 3
or more thread dumps then run all the out put from those through
Seestack to help you identify the problems.
Wil Genovese
One man with courage makes a majority.
-Andrew Jackson
A fine is a tax for doing wrong. A tax is a fine for doing well.
On Dec 3, 2008, at 9:53 AM, Wil Genovese wrote:
> Philip,
>
> Based on the load you mentioned earlier and the other data you've
> given me here is what I'd do.
>
> 1. upgrade the JVM to 1.6_10
>
> 2. backup my jvm.config and then edit the java.args line to this.
>
> java.args= -server -DJINTEGRA_NATIVE_MODE -DJINTEGRA_PREFETCH_ENUMS -
> Xmx512m -Xms512m -XX:MaxPermSize=128m -XX:PermSize=128m -XX:
> +UseParallelGC -Dsun.rmi.dgc.client.gcInterval=600000 -
> Dsun.rmi.dgc.server.gcInterval=600000
> Dcoldfusion.rootDir={application.home}/
>
> 3. next take several full stack dumps (not just a single part of one)
> and run it through seestack. It will give you comparisons between
> each stack dump and identify threads that are present from stack dump
> to stack dump. These are the hangers or slow threads.
>
> 4. since your traffic isn't so great that debugging will hurt
> performance, I would then turn on debugging (based on your IP address)
> and then analyze every query that is running per request.
>
> 5. use fusion reactor alerts to alert you to a slow running thread. FR
> has some good tools to help you see what is happening with the thread.
>
> Typical points of pain I've seen
> 1. JVM config not right - not enough memory heap, not enough perm
> memory, GC interval happening to often or not often enough.
> 2. Queries returning more results than you expected. Many times
> people put CFIF statements in their queries and not all conditions are
> accounted for thus an open ended where clause may try to return all
> the rows of a table. This can cause issues for large tables.
> 3. critical external dependancies are slow or failing. Besides DB
> access (check this also) , things like CFHTTP, external web services,
> mail server (CFPOP) and file system access can cause problems if your
> not setting a time out and not gracefully handling the times when the
> external dependancy is unavailable.
> 4. excessive looping or external dependancies can cause issues even if
> those dependancies are "fast". Looping ten times over a resource call
> that takes 1/2 second to run still give a thread time of 5 seconds
> plus the time to process the rest of the thread.
>
> This is just the start - if none of the above solves the problems (or
> at least make things better) you may have to get in deeper. There is
> always the option of doing a full code review. settings up a second
> server with nothing but CF on it and see if you can duplicate the
> problems. If not then you may be looking at the server itself more
> than CF and code. If yes, then use this test server to hammer upon.
>
>
>
> Wil Genovese
> Sr. Web Application Developer
>
> One man with courage makes a majority.
> -Andrew Jackson
>
> A fine is a tax for doing wrong. A tax is a fine for doing well.
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free Trial
http://ad.doubleclick.net/clk;207172674;29440083;f
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:316196
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
