[Swift-devel] hprof profiling of coaster services

[Mihael Hategan]

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.