[ 
https://issues.apache.org/jira/browse/TS-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533310#comment-13533310
 ] 

Jack Bates commented on TS-1528:
--------------------------------

I re-tested with the latest master (544e64678eecb80a63b88b9efe573ecb42836c24), 
here is the output with the "cache_init" tag: 
http://nottheoilrig.com/trafficserver/201212160/stderr

I notice the new log message explaining that it will allocate over 3GB of 
memory for directory entries for our 3TB disk (with min_average_object_size 
8K), and I notice that the overflow in the ats_memalign failure log message is 
gone. I think this issue is resolved, thank you for your support!

We've now been running Traffic Server (release 3.2.0) for a couple months with 
the 3TB disk, min_average_object_size 64K, and 
proxy.config.cache.ram_cache.size 32M. It works, but I notice that when a lot 
of users are online, downloading even cached files is slow. I'm not sure what 
specifically is the problem, maybe our CPU and RAM aren't sufficient. The disk 
is external, connected with USB2. I think fast disk access is important to 
Traffic Server, so maybe the USB bus is the weakest link?

Long term, we plan to upgrade to 64-bit hardware with at least 4GB of RAM and 
OOE support, ideally an i3 or i5 processor. I'm looking at stuff from Zotac and 
Shuttle. Meanwhile I plan to scrap the 3TB disk and install Traffic Server on 
an SD card, then use the entire internal 160GB disk as a raw device. I guess 
this will need about 160MB of RAM for directory entries with default settings, 
and another 160MB for RAM cache, which is well withing our 1GB of RAM.
                
> ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
> ---------------------------------------------------------------
>
>                 Key: TS-1528
>                 URL: https://issues.apache.org/jira/browse/TS-1528
>             Project: Traffic Server
>          Issue Type: Bug
>    Affects Versions: 3.2.0
>         Environment: Debian testing (wheezy) on i686
>            Reporter: Jack Bates
>            Assignee: James Peach
>             Fix For: 3.3.3
>
>
> I consistently get the following error whenever I try to start Traffic Server 
> (release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to 
> check if it behaves any differently, but I consistently reproduce this same 
> error whenever I try to start it, too
> Here's my configuration, which is pretty minimal: 
> http://nottheoilrig.com/trafficserver/201210120/
> What details can I provide to help debug this? James Peach suggested 
> attaching some kind of dump of the volume header: 
> http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
> {code}
> administrator@debian$ TS_ROOT=/home/administrator/trafficserver 
> trafficserver/traffic_server
> [TrafficServer] using root directory '/home/administrator/trafficserver'
> FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 - 
> insufficient memory
> trafficserver/traffic_server - STACK TRACE:
> trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
> trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
> trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
> trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
> trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
> trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
> trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
> trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
> trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
> trafficserver/traffic_server(main+0x178d)[0x80c572d]
> /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
> trafficserver/traffic_server[0x80cabdd]
> administrator@debian:~$ 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to