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

[Michael Wilde]

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.

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