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

Danny Shporer commented on TS-981:
----------------------------------

I have not tried to reproduce with reverse or forward proxy.
I did try to reproduce in debug build but without success - my tool was not 
able to reach 25K TPS in debug build. It only reached around 16K TPS and there 
was no exception.

The problem seems to be with the libev support in ATS. Without it in my Linux 
environment when plain epoll is used (./configure --enable-tproxy) it does not 
happen and I have been working this way since (I have reached round 34K TPS).
There is another issue regarding heavy load in transparent proxy - the Linux 
TPROXY stack only takes into account the local addresses when using dynamic 
bind (bind without specifying a port). I opened a new bug for this one - 
TS-1075.
                
> ATS as transparent proxy crashes under heavy load
> -------------------------------------------------
>
>                 Key: TS-981
>                 URL: https://issues.apache.org/jira/browse/TS-981
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0
>         Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled 
> with TPROXY support.
> ATS compiled as: ./configure --enable-tproxy --enable-libev
>            Reporter: Danny Shporer
>            Priority: Critical
>             Fix For: 3.1.2
>
>         Attachments: records.config
>
>
> ATS crashes under heavy load testing - around 25,000 HTTP transactions per 
> second.
> I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens.
> GDB info:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x42174940 (LWP 6663)]
> 0x000000000068fd4b in modify (this=0x2aaaab12c628, event=<value optimized 
> out>, e=<value optimized out>) at P_UnixNet.h:536
> 536         fd_change(event_loop->eio, eio.fd, 0);
> (gdb) bt
> #0  0x000000000068fd4b in modify (this=0x2aaaab12c628, event=<value optimized 
> out>, e=<value optimized out>) at P_UnixNet.h:536
> #1  NetHandler::mainNetEvent (this=0x2aaaab12c628, event=<value optimized 
> out>, e=<value optimized out>) at UnixNet.cc:432
> #2  0x00000000006bfc4f in EThread::process_event (this=0x2aaaab12b010, 
> e=0xf44570, calling_code=5) at I_Continuation.h:146
> #3  0x00000000006c055c in EThread::execute (this=0x2aaaab12b010) at 
> UnixEThread.cc:262
> #4  0x00000000006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88
> #5  0x0000003e9dc0673d in start_thread () from /lib64/libpthread.so.0
> #6  0x0000003e9d0d44bd in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x42174030:
>  rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f
>  inlined into frame 1
>  source language c++.
>  Arglist at unknown address.
>  Locals at unknown address, Previous frame's sp in rsp

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to