[Swift-devel] Re: Persistent coaster service fails after several runs

Justin M Wozniak wozniak at mcs.anl.gov
Tue Nov 30 16:57:45 CST 2010


I'm on Intrepid so it's an IBM heap dump.  There's a good one there in 
~wozniak/Public/heapdumps .

The byte[]s are definitely associated with TCPChannel but that's all I 
have been able to figure out so far- I don't see where they are retained.

It is possible that the reader is generating the bytes faster than the 
network can push them out, so we just need to tighten up the throttle?

On Tue, 30 Nov 2010, Mihael Hategan wrote:

> Can you make a heap dump of the relevant issue?
>
> On Tue, 2010-11-30 at 09:59 -0600, Justin M Wozniak wrote:
>> Along these lines, I'm looking at memory usage in Coasters.  There's a
>> plot attached below- usage spikes when the workers start running.
>>
>> 96% of the usage is byte[] which makes me think it could be KarajanChannel
>> stuff...
>>
>> http://www.ci.uchicago.edu/wiki/bin/view/SWFT/PerformanceNotes#Memory
>>
>> On Sun, 28 Nov 2010, Michael Wilde wrote:
>>
>>> This fix looks great so far - Ive tested with varying workflow sizes and delays, and have not seen any problems.
>>>
>>> - Mike
>>
>
>
>

-- 
Justin M Wozniak



More information about the Swift-devel mailing list