continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Lustig ...@marclustig.com>
Subject Re: Profiling results for Continuum
Date Tue, 23 Jun 2009 13:54:28 GMT

Yes, you were right.
Now I have the results for a "normal" situation, about 1 hour after
deployment. 
The tomcat-process consuming between 150 and 200 % of the machine.

http://www.nabble.com/file/p24166543/Call_Tree_3.html Call_Tree_3.html 


Emmanuel Venisse-2 wrote:
> 
> I don't see your previous results in this file.
> The output you attached seems to be ok for our startup process because we
> have lot of beans to load with spring and lot of datas to load with JPOX.
> 
> Emmanuel
> 
> On Tue, Jun 23, 2009 at 2:16 PM, Marc Lustig <ml@marclustig.com> wrote:
> 
>>
>> Yeah, sure. I have attached an html-file. I hope it will be accessible
>> thru
>> nabble.
>> http://www.nabble.com/file/p24164853/Call_Tree_2.html Call_Tree_2.html
>>
>>
>>
>> Emmanuel Venisse-2 wrote:
>> >
>> > It it possible to have a stack trace of this threads to know where to
>> look
>> > in the code?
>> >
>> > Emmanuel
>> >
>> > On Mon, Jun 22, 2009 at 9:28 AM, Marc Lustig <ml@marclustig.com> wrote:
>> >
>> >>
>> >> Hi there,
>> >> as requested I repost this here.
>> >>
>> >> our teams have been suffering from the bad performance of the
>> >> Continuum-UI
>> >> for a long time . I found now the time to profile one of our servers
>> >> running
>> >> 3 Continuum-1.2.2-instances (webapps) on a single Tomcat6, JDK6, RHEL4
>> >> and
>> >> Oracle-RAC as database-backend.
>> >>
>> >> The tomcat-JVM is consuming between 150 and 200 % of our dual-core
>> >> Xeon-server.
>> >> This is just the tomcat-JVM, not any maven-process running aside.
>> >> And I am not talking about peaks, the load is as high like that for
>> >> hours.
>> >>
>> >> This is a snapshot taken by Jprofiler at a time without any
>> user-activity
>> >> on
>> >> one of the UI's.
>> >>
>> >> the 3 threads causing the highest load are:
>> >> 37,3% - 54.415 ms - 5 inv.
>> >> org.jpox.AbstractPersistenceManager.detachCopyAll
>> >> 13,6% - 19.842 ms - 14 inv.
>> >> org.codehaus.plexus.jdo.PlexusJdoUtils.getObjectById
>> >> 34,5% - 50.362 ms - 4.480 inv.
>> >> edu.emory.mathcs.backport.java.util.concurrent.BlockingQueue.poll
>> >> (100% = total load caused by the JVM)
>> >>
>> >> The first 2 threads are caused by the JDO-impl.  Is it possible that
>> >> Continuum has an extremely "bad" fetching stragety, e. g. doing all
>> kinds
>> >> of
>> >> unnecessary loading cascades? This is my first impression.
>> >>
>> >> About the 3rd thread, I have no idea why this BlockingQueue is causing
>> >> such
>> >> a tremendous load.
>> >> What is the purpose of this thread? Can it be optimized.
>> >>
>> >> The slow performance is not only while adding new project groups.
>> There
>> >> is
>> >> a
>> >> high CPU-load almost constantly between 100 and 200 % (on dual core):
>> >>
>> >> 12795 tomcat    16   0  171   7238:01 40.9 12.0g 6.3g  10m S java
>> >>
>> >> thanks
>> >>
>> >> Marc
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Profiling-results-for-Continuum-tp24142787p24142787.html
>> >> Sent from the Continuum - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Profiling-results-for-Continuum-tp24142787p24164853.html
>> Sent from the Continuum - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Profiling-results-for-Continuum-tp24142787p24166543.html
Sent from the Continuum - Dev mailing list archive at Nabble.com.


Mime
View raw message