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 <m...@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. > >
