[Swift-devel] hprof profiling of coaster services

[Mihael Hategan]

I also committed a patch (cog r2409) to give the service job a lower
priority (nice 10).

This won't however prevent the process from consuming 100% CPU if that
much CPU is available.

On Wed, 2009-06-24 at 18:30 -0500, Mihael Hategan wrote:
> Try the following:
> 
> In the source tree, edit
> cog/modules/provider-coaster/resources/log4j.properties and change the
> INFO categories to WARN.
> 
> Then re-compile and see if the usage is still high.
> 
> On Tue, 2009-06-23 at 17:11 -0500, Allan Espinosa wrote:
> > ok this looks like a good replicable case.
> > 
> > the workflow is 2000 invocations of touch using 066-many.swift
> > 
> > run04.tar.gz (logs and a "top -b"  dump for the coaster service).  cpu
> > utilization averages to 99-100% .   i ran this for five trials and got
> > the same results.
> > 
> > run05.tar.gz - same run with profiling information. in java.hprof.bin
> > 
> > 2009/6/19 Mihael Hategan <hategan at mcs.anl.gov>:
> > > On Fri, 2009-06-19 at 18:30 -0500, Allan Espinosa wrote:
> > >> here's a script recording without profiling of top:
> > >>
> > >> http://www.ci.uchicago.edu/~aespinosa/top_vanilla.gz
> > >>
> > >> it still consumes some cpu. but does not spike to 200% utilization.
> > >
> > > Right, 10% != 200%.
> > >
> > > Now, as you're probably already guessing, I would need:
> > > 1. a situation (workflow/site/etc.) in which the usage does go crazy
> > > without the profiler (as in what triggered you getting kicked off
> > > ranger); repeatable
> > > 2. a profiler dump of a run in such a situation
> > >
> > > Btw, the ranger issue, where was swift running?
> > 
> > on communicado.
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel