Ok, Thanks :-) --
Best Regards BaiYang baiy...@gmail.com http://baiy.cn **** < END OF EMAIL > **** From: Willy Tarreau Date: 2015-11-24 23:05 To: baiyang CC: Lukas Tribus; haproxy Subject: Re: Re: CPU 100% when waiting for the client timeout On Tue, Nov 24, 2015 at 03:06:15PM +0800, baiyang wrote: > I caught both strace log and show sess all output this time: > http://baiy.cn/tmp/log-1124.rar ... and it paid quickly : 0x2890810: [24/Nov/2015:14:38:54.760319] id=708867 proto=tcpv4 source=182.148.111.97:6085 flags=0x24348e, conn_retries=3, srv_conn=(nil), pend_pos=(nil) frontend=http-in (id=2 mode=http), listener=? (id=1) addr=10.171.250.166:80 backend=WebSvr (id=10 mode=http) addr=10.159.35.0:15802 server=ws0 (id=1) addr=10.161.182.74:80 task=0x27f1bc0 (state=0x04 nice=0 calls=412591903 exp=<PAST>, running age=10m49s) txn=0x2890b80 flags=0x28000000 meth=1 status=200 req.st=MSG_DONE rsp.st=MSG_ERROR waiting=0 si[0]=0x2890a08 (state=EST flags=0x00 endp0=CONN:0x290ca60 exp=<NEVER>, et=0x000) si[1]=0x2890a28 (state=CLO flags=0x190 endp1=CONN:0x286fab0 exp=<NEVER>, et=0x000) co0=0x290ca60 ctrl=tcpv4 xprt=RAW data=STRM target=LISTENER:0x26ff190 flags=0x0025b360 fd=24 fd.state=52 fd.cache=0 updt=0 co1=0x286fab0 ctrl=NONE xprt=NONE data=STRM target=SERVER:0x276a280 flags=0x0022a000 fd=14 fd_spec_e=52 fd_spec_p=0 updt=0 req=0x2890820 (f=0x04e060 an=0x0 pipe=0 tofwd=0 total=523) an_exp=<NEVER> rex=<NEVER> wex=? buf=0x6e3100 data=0x6e3114 o=0 p=0 req.next=0 i=0 size=0 res=0x2890860 (f=0x8407c060 an=0x0 pipe=0 tofwd=0 total=91200) an_exp=<NEVER> rex=? wex=4m11s buf=0x2842fb0 data=0x2842fc4 o=12296 p=6632 rsp.next=0 i=0 size=12296 See "calls=412591903" ? we're spending our time calling this one, and "exp=<PAST>" means it has expired. So we do have a bug making this session ignore the expired timeout, but since we have all the flags here, I hope I'll find my way in the code to understand why it doesn't get killed. Interestingly, 7 sessions form this IP (and only this one) experienced the same issue, so there could be something that this client manages to reproduce more easily than the other ones which trigger the issue. I'm keeping my fingers crossed, hoping that the next mail I'll send to you will contain a patch to test, but I'm not promising anything yet :-) Thanks! Willy
