On 9/20/2010 9:45 PM, Pranav Desai wrote: > > This is with 2.1.2. Maybe I will try the latest SVN.
If you could that would be useful as the disk layout changed a bit when support for 4096 sector size drives was added. > Also > note that I am testing it with a file based cache. Do you think there > could be something there ? Your file size is relatively large, so if your number of clients is large and your file based cache is small you could be running into wrap-around issues... where a slow client can't write the whole object before the disk wraps. How big of a file cache are you running ? How many clients ? I am using raw disk and at 10 clients (debug build) it I am doing between 5 and 3 ops/sec or between 45 and 75 MB/sec with a total latency of around 3 seconds but probably spiking to more like 5+... which means I would require a cache size of at least 1GB probably a lot more to be safe (because of random latency spikes). The code *should* recognize wrap-around, but because it is typically not a problem in adequately sized production systems it might not be reported. > > >> If can provide access to a gdb session with the crash I might be able to >> figure >> out what is going on... >> > > I was short on time so couldn't debug it any further ... hopefully I > can get it done tomorrow ... > > -- Pranav > >> john >> >> >> On 9/20/2010 6:20 PM, Pranav Desai wrote: >>> On Thu, Sep 16, 2010 at 3:30 PM, Pranav Desai <[email protected]> >>> wrote: >>>> On Thu, Sep 16, 2010 at 2:03 PM, Leif Hedstrom <[email protected]> wrote: >>>>> On 09/16/2010 02:45 PM, Pranav Desai wrote: >>>>> >>>>> On Thu, Sep 16, 2010 at 12:33 PM, Leif Hedstrom <[email protected]> wrote: >>>>> >>>>> On 09/16/2010 01:26 PM, Pranav Desai wrote: >>>>> >>>>> Hi! >>>>> >>>>> I am running a load test with some video files to see . I am using >>>>> curl-loader to generate the load. I have modified it to add a random >>>>> number to the URLs before sending so I can test with a single URL and >>>>> still stress the cache. The webserver is a lighttpd server with >>>>> rewrite rules to translate the random strings back to a common URL. >>>>> The URL is essentially a 15MB video file. I can provide more details >>>>> on the setup if needed. >>>>> >>>>> Ok, I've created https://issues.apache.org/jira/browse/TS-441 with this >>>>> information. If you can find a core file (or, run traffic_server under >>>>> gdb), >>>>> and get a stack trace, that would be very helpful. Also, when it crashes, >>>>> you might get a stack trace in /var/log/messages and/or one of the log >>>>> files >>>>> in the .../var/log/trafficserver directory. >>>>> >>>>> >>> >>> I got the stack trace. I have updated the bug with the trace, but here it >>> is. >>> >>> FATAL: HTTP.cc:1526: failed assert `!"unknown m_polarity"` >>> ./bin/traffic_server - STACK TRACE: >>> ./bin/traffic_server(ink_fatal+0x86)[0x6f2056] >>> ./bin/traffic_server(_ink_assert+0x81)[0x6f0d61] >>> ./bin/traffic_server(_ZN11HTTPHdrImpl9unmarshalEl+0x35)[0x5ea385] >>> ./bin/traffic_server(_ZN7HdrHeap9unmarshalEiiPP14HdrHeapObjImplP11RefCountObj+0x146)[0x5df926] >>> ./bin/traffic_server(_ZN8HTTPInfo9unmarshalEPciP11RefCountObj+0xc5)[0x5ea205] >>> ./bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x750)[0x6648a0] >>> ./bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x26)[0x66ce26] >>> ./bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x22f)[0x6e7c0f] >>> ./bin/traffic_server(_ZN7EThread7executeEv+0x1aa)[0x6e810a] >>> ./bin/traffic_server[0x6e76da] >>> /lib64/libpthread.so.0[0x7f4a565e52e7] >>> /lib64/libc.so.6(clone+0x6d)[0x32a18ce3bd] >>> >>> >>> I will try to dig deeper, but if have any ideas or suggestions I can >>> try those out. >>> >>> Thanks >>> -- Pranav >> >>
