UPDATE RE: Stats error
I got it working.. thank you - Alex From: DeMarco, Alex [mailto:alex.dema...@suny.edu] Sent: Friday, December 07, 2012 7:18 PM To: haproxy@formilux.org Subject: Stats error I am trying to get stats enable to work. However, every time I try to start haproxy I get the following error: 'stats' ignored because frontend has no backend capability. I have backend rules in place so I am not sure what else I am missing.. Any ideas? Thank you.. Alex
Stats error
I am trying to get stats enable to work. However, every time I try to start haproxy I get the following error: 'stats' ignored because frontend has no backend capability. I have backend rules in place so I am not sure what else I am missing.. Any ideas? Thank you.. Alex
Re: Seeing high CPU usage with obscene number of calls to epoll_wait
On Fri, Dec 7, 2012 at 9:32 PM, Willy Tarreau wrote: > Hi Brian, > > On Fri, Dec 07, 2012 at 10:54:28AM +0100, Bryan Berry wrote: >> ugh, sorry I didn't mention that I ran >> >> rm haproxy-1.5-dev14 -rf >> wget http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev14.tar.gz >> tar xvzf haproxy-1.5-dev14* && cd haproxy-1.5-dev14 >> patch -p1 < 0001-BUG-MAJOR-raw_sock-must-check-error-code-on-hangup.patch >> patch -p1 < 0002-BUG-MAJOR-polling-do-not-set-speculative-events-on-E.patch >> make TARGET=linux26 ARCH=x86_64 USE_LINUX_SPLICE=1 CPU=native >> USE_VSYSCALL=1 \ USE_STATIC_PCRE=1 USE_OPENSSL=1 >> make install >> >> I also did a hash of the new haproxy binary to ensure that is different >> from the old one > > Thanks for reporting this. Then I'll have to go back to Exceliance this > week-end, as I can only reproduce the issue between my laptop running > haproxy and a small machine there running httpterm. No other combination > seem to work. > > Best regards, > Willy > Well, I have an ALOHA 5.5 running in front of an exchange 2013 which had the issue this afternoon :) Feel free to use it, but be patient, it comes from time to time. cheers >
Re: Seeing high CPU usage with obscene number of calls to epoll_wait
Hi Brian, On Fri, Dec 07, 2012 at 10:54:28AM +0100, Bryan Berry wrote: > ugh, sorry I didn't mention that I ran > > rm haproxy-1.5-dev14 -rf > wget http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev14.tar.gz > tar xvzf haproxy-1.5-dev14* && cd haproxy-1.5-dev14 > patch -p1 < 0001-BUG-MAJOR-raw_sock-must-check-error-code-on-hangup.patch > patch -p1 < 0002-BUG-MAJOR-polling-do-not-set-speculative-events-on-E.patch > make TARGET=linux26 ARCH=x86_64 USE_LINUX_SPLICE=1 CPU=native > USE_VSYSCALL=1 \ USE_STATIC_PCRE=1 USE_OPENSSL=1 > make install > > I also did a hash of the new haproxy binary to ensure that is different > from the old one Thanks for reporting this. Then I'll have to go back to Exceliance this week-end, as I can only reproduce the issue between my laptop running haproxy and a small machine there running httpterm. No other combination seem to work. Best regards, Willy
Re: HAProxy statistics report page
search 'stats enable' in doc. Bests, -Igor On Fri, Dec 7, 2012 at 10:08 PM, DeMarco, Alex wrote: > Question, on demo.1wt.eu what was used to create this? Is it a function in > HAProxy? I’ve been looking thru the doc and cannot seem to find it. > > > > Thank you. > > - Alex
HAProxy statistics report page
Question, on demo.1wt.eu what was used to create this? Is it a function in HAProxy? I've been looking thru the doc and cannot seem to find it. Thank you. - Alex
Re: With SSH Load balancing, haproxy not responding.
I do not believe you are correct. I am experiencing the same problem, only in a much smaller timeframe than described. As soon as I run haproxy 1.5-dev14 it works wonderfully for the first few minutes. After that, the number of connections drops significantly below the limit for each backend. Attempting to connect with telnet will either fail or take a very, very long time.
Re: Seeing high CPU usage with obscene number of calls to epoll_wait
sorry am scatter-brained today here is the correct link for my show-sess.out https://docs.google.com/open?id=0BzPvBvLIIq7NelNrbmRmY3BkdFE On Fri, Dec 7, 2012 at 10:54 AM, Bryan Berry wrote: > ugh, sorry I didn't mention that I ran > > rm haproxy-1.5-dev14 -rf > wget http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev14.tar.gz > tar xvzf haproxy-1.5-dev14* && cd haproxy-1.5-dev14 > patch -p1 < 0001-BUG-MAJOR-raw_sock-must-check-error-code-on-hangup.patch > patch -p1 < > 0002-BUG-MAJOR-polling-do-not-set-speculative-events-on-E.patch > make TARGET=linux26 ARCH=x86_64 USE_LINUX_SPLICE=1 CPU=native > USE_VSYSCALL=1 \ USE_STATIC_PCRE=1 USE_OPENSSL=1 > make install > > I also did a hash of the new haproxy binary to ensure that is different > from the old one > > > On Fri, Dec 7, 2012 at 10:50 AM, Bryan Berry wrote: > >> Unfortunately I am still seeing the same issue :( >> >> 168.100.2.181, 168.100.2.237, 168.100.2.195, 168.100.2.183 # these >> have been changed from originals >> >> here is my show-sess.out again >> https://docs.google.com/open?id=0BzPvBvLIIq7NLVpFRWtvOUxyZ0U >> >> >> On Fri, Dec 7, 2012 at 12:28 AM, Willy Tarreau wrote: >> >>> Hi Bryan, >>> >>> here come two fixes that I have pushed to the Git tree. They will be >>> in friday morning's snapshot, but I'm attaching the patches. >>> >>> The bug is complex to reproduce, it requires a specific timing that I >>> can only get with a combination of two machines and a certain number >>> of concurrent connections. It manifests when an error is reported at >>> the same time as a clean connection close. Only the connection close >>> was handled, the error did not cause an abort of the connection. The >>> issue is that afterwards, the error flag was lost, and the polling >>> remained active, causing the loops you have noticed. These loops all >>> eventually terminate thanks to the timeouts in the configuration. >>> >>> The two patches address different aspects of the issue, the first one >>> being for a real bug and the second one more about a misdesign from me >>> which fuels the bug. >>> >>> I'd like to really thank you for the amount of precise information you >>> provided, that was really helpful, especially because I was suspecting >>> totally unrelated issues (checks) and would not have found without your >>> help. >>> >>> I'd be happy if you can test to confirm that the issue does not reappear >>> anymore. Once I get your go (and possibly other pending fixes that might >>> appear in between), I'll issue dev15 to avoid causing issues to other >>> users. >>> >>> Thanks! >>> Willy >>> >>> >> >
Re: Seeing high CPU usage with obscene number of calls to epoll_wait
ugh, sorry I didn't mention that I ran rm haproxy-1.5-dev14 -rf wget http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev14.tar.gz tar xvzf haproxy-1.5-dev14* && cd haproxy-1.5-dev14 patch -p1 < 0001-BUG-MAJOR-raw_sock-must-check-error-code-on-hangup.patch patch -p1 < 0002-BUG-MAJOR-polling-do-not-set-speculative-events-on-E.patch make TARGET=linux26 ARCH=x86_64 USE_LINUX_SPLICE=1 CPU=native USE_VSYSCALL=1 \ USE_STATIC_PCRE=1 USE_OPENSSL=1 make install I also did a hash of the new haproxy binary to ensure that is different from the old one On Fri, Dec 7, 2012 at 10:50 AM, Bryan Berry wrote: > Unfortunately I am still seeing the same issue :( > > 168.100.2.181, 168.100.2.237, 168.100.2.195, 168.100.2.183 # these have > been changed from originals > > here is my show-sess.out again > https://docs.google.com/open?id=0BzPvBvLIIq7NLVpFRWtvOUxyZ0U > > > On Fri, Dec 7, 2012 at 12:28 AM, Willy Tarreau wrote: > >> Hi Bryan, >> >> here come two fixes that I have pushed to the Git tree. They will be >> in friday morning's snapshot, but I'm attaching the patches. >> >> The bug is complex to reproduce, it requires a specific timing that I >> can only get with a combination of two machines and a certain number >> of concurrent connections. It manifests when an error is reported at >> the same time as a clean connection close. Only the connection close >> was handled, the error did not cause an abort of the connection. The >> issue is that afterwards, the error flag was lost, and the polling >> remained active, causing the loops you have noticed. These loops all >> eventually terminate thanks to the timeouts in the configuration. >> >> The two patches address different aspects of the issue, the first one >> being for a real bug and the second one more about a misdesign from me >> which fuels the bug. >> >> I'd like to really thank you for the amount of precise information you >> provided, that was really helpful, especially because I was suspecting >> totally unrelated issues (checks) and would not have found without your >> help. >> >> I'd be happy if you can test to confirm that the issue does not reappear >> anymore. Once I get your go (and possibly other pending fixes that might >> appear in between), I'll issue dev15 to avoid causing issues to other >> users. >> >> Thanks! >> Willy >> >> >
Re: Seeing high CPU usage with obscene number of calls to epoll_wait
Unfortunately I am still seeing the same issue :( 168.100.2.181, 168.100.2.237, 168.100.2.195, 168.100.2.183 # these have been changed from originals here is my show-sess.out again https://docs.google.com/open?id=0BzPvBvLIIq7NLVpFRWtvOUxyZ0U On Fri, Dec 7, 2012 at 12:28 AM, Willy Tarreau wrote: > Hi Bryan, > > here come two fixes that I have pushed to the Git tree. They will be > in friday morning's snapshot, but I'm attaching the patches. > > The bug is complex to reproduce, it requires a specific timing that I > can only get with a combination of two machines and a certain number > of concurrent connections. It manifests when an error is reported at > the same time as a clean connection close. Only the connection close > was handled, the error did not cause an abort of the connection. The > issue is that afterwards, the error flag was lost, and the polling > remained active, causing the loops you have noticed. These loops all > eventually terminate thanks to the timeouts in the configuration. > > The two patches address different aspects of the issue, the first one > being for a real bug and the second one more about a misdesign from me > which fuels the bug. > > I'd like to really thank you for the amount of precise information you > provided, that was really helpful, especially because I was suspecting > totally unrelated issues (checks) and would not have found without your > help. > > I'd be happy if you can test to confirm that the issue does not reappear > anymore. Once I get your go (and possibly other pending fixes that might > appear in between), I'll issue dev15 to avoid causing issues to other > users. > > Thanks! > Willy > >
