[Swift-devel] Overview of coaster block-allocation-version issues

[Mihael Hategan]

On Fri, 2009-06-19 at 09:40 -0500, Michael Wilde wrote:
> might in addition be good to start with empty logs, and summarize the 
> record type counts in the log. That 5GB log size is a bit of a concern.
> Might be something simple like n^2 debug logging.

:)

No. It's verbose because the software is new and at this point it's
better to have more information than less.

> 
> On 6/19/09 8:47 AM, Mihael Hategan wrote:
> > On Fri, 2009-06-19 at 08:35 -0500, Mihael Hategan wrote:
> >> On Fri, 2009-06-19 at 08:31 -0500, Michael Wilde wrote:
> >>> On 6/19/09 8:23 AM, Mihael Hategan wrote:
> >>>> On Fri, 2009-06-19 at 07:47 -0500, Michael Wilde wrote:
> >>>>> More thoughts on this:
> >>>>>
> >>>>> (2) is a showstopper on Ranger (and possible elsewhere) and hence a much 
> >>>>> more important issue than (1).
> >>>>>
> >>>>> It seems like this problem merits a 2-pronged attack:
> >>>>>
> >>>>> a) reduce the overhead. Is it logging, or intrinsic to the protocol?
> >>>>>    -- is it obvious from the log whats causing the high overhead?
> >>>>>    -- its it a situation where the overhead is incurred even when
> >>>>>       jobs are not running, just queued?
> >>>> Some profiling needs to be done.
> >>> Zhao or Allan, can you reproduce the problem on TeraPort or UC Teragrid, 
> >>> using a simple script and dummy app so that Mihael can readily reproduce?
> >>>
> >>> Mihael, do you want them to run with profiling and post results?
> >> That would be great. Get a hprof dump with cpu tracing enabled. See
> >> http://java.sun.com/developer/technicalArticles/Programming/HPROF.html
> > 
> > Bootstrap.java will also need to be modified for the relevant profiling
> > parameters to be passed to the coaster service JVM.
> > 
> > addDebuggingOptions() may be the right place to do so.
> > 
> >