Do you have lot of projectgroups/projects/buildresults? I started to review our JPOX calls and to fix some of them to get less datas.
Emmanuel On Tue, Jun 23, 2009 at 3:54 PM, Marc Lustig <m...@marclustig.com> wrote: > > 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 <m...@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 <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. > >> >> > >> >> > >> > > >> > > >> > >> -- > >> 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. > >
