On Thu, May 26, 2011 at 5:11 PM, aniket ray <aniket....@gmail.com> wrote:
> On Thu, May 26, 2011 at 7:39 AM, John Plevyak <jplev...@acm.org> wrote:
>> Ah, yes, that is 64MB. The freelist is thread safe, although a missing
>> "volatile"
>> declaration caused it to fail to be so for the 32-bit version with recent
>> versions
>> of gcc. That is the reason to update to 2.1.8. Are you seeing your problem
>> with
>> a 32-bit or 64-bit build?
>>
>> john
>
> I'm seeing it with the 32-bit version but I'm also seeing it with 2.1.8.
> Based on smaps, it seems the heap is pretty quickly using up the
> virtual memory address space with a very low Rss usage.
> After this posix_memalign starts failing with an ENOMEM.
> I think this implies memory fragmentation.
> Any ideas? Is this a known issue?
>
> -aniket
>
>>
I think the issue is being caused by two optimizations at HttpTunnel.cc.
First At HttpTunnel.cc:421,
chunked_buffer->write(dechunked_reader, write_val);
This clones existing bufferblocks and adds them to the writer list.
Second at HttpTunnel.cc:426, chunked_buffer->write("\r\n", 2);
This allocates a 64MB memory buffer, expecting that more things would
be written to bufferblock . But instead of writing our first
optimization gets called again. Thus this huge buffer gets wasted,
i.e. only 2 bytes out of 64MB get used.
I'm sure I'm missing something but not sure what.
Thanks,
-aniket
>> On Wed, May 25, 2011 at 11:36 AM, aniket ray <aniket....@gmail.com> wrote:
>>
>>> On Wed, May 25, 2011 at 8:12 PM, John Plevyak <jplev...@acm.org> wrote:
>>> > There is no 64MB freelist unless you have created one yourself. The
>>> buffer
>>> > freelists max out at 2MB and unless you are caching files you should not
>>> see
>>> > them allocated.
>>> >
>>> > john
>>> >
>>>
>>> I might have been mistaken but it seems ioBufAllocator[14] has a
>>> type_size of 2M and a chunk_size of 32 (DEFAULT_HUGE_BUFFER_NUMBER) at
>>> init_buffer_allocators().
>>>
>>> This initializes a freelist that tries to memalign 2M * 32 each time a
>>> MIOBuffer::write is called.
>>> Is my understanding incorrect? Just to add, I haven't created any
>>> freelists.
>>>
>>> Thanks,
>>> -aniket
>>>
>>>
>>> > On Wed, May 25, 2011 at 2:24 AM, aniket ray <aniket....@gmail.com>
>>> wrote:
>>> >
>>> >> On Tue, May 24, 2011 at 9:52 PM, Leif Hedstrom <zw...@apache.org>
>>> wrote:
>>> >> > On 05/24/2011 10:14 AM, aniket ray wrote:
>>> >> >>
>>> >> >> It's trafficserver 2.1.5-unstable
>>> >> >
>>> >> > Can you try v2.1.8, or even better, current trunk, I know we fixed
>>> >> several
>>> >> > bugs related to this code since v2.1.5.
>>> >> >
>>> >> I ported my plugin to the new version of ATS to get it running to test
>>> >> the crasher on v2.1.8. I'm getting the exact same crash with the same
>>> >> call stack.
>>> >>
>>> >> It seems that my thread safety diagnosis might not have been correct.
>>> >> It is trying to allocate 64MB blocks at a time off the freelist till
>>> >> memalign starts failing. Is this the expected behaviour?
>>> >>
>>> >> > -- leif
>>> >> >
>>> >> > Getting trunk:
>>> >> >
>>> >> > svn co http://svn.apache.org/repos/asf/trafficserver/traffic/trunk/
>>> >> >
>>> >>
>>> >> I could not get this working. Does this need a specific version of
>>> >> automake? I have 1.11.
>>> >>
>>> >> Thanks,
>>> >> -aniket
>>> >>
>>> >
>>>
>>
>
