[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