tune.bufsize issue with send-proxy / accept-proxy SSL setup
Hello Our HAProxy 1.5~dev21 setup looks like this: client browser - haproxy1 - haproxy2 - web servers - client browser sends as https. - haproxy1 receives with mode tcp frontend, and sends using mode tcp backend with send-proxy. - haproxy2 receives with mode http frontend with ssl accept-proxy, and sends using mode http backend to web servers. The problem: when clients send a POST requests with 8K payload, the request will appear to hang in the client, and eventually be aborted after 30 seconds. (Our timeout client and timeout server settings are 30s.) So the client receives no response and I believe HAProxy closes the connection. A workaround/fix for this problem is to set tune.bufsize 24576 on the second haproxy above (haproxy2). (I assume lowering tune.maxrewrite instead may work as well.) However, the documentation recommends against changing tune.bufsize. And we really don't want to limit POST payload size. Is this expected behavior? Especially considering that it happens to POST requests and not only GET requests in our setup. Regards, Oskar Liljeblad
Re: tune.bufsize issue with send-proxy / accept-proxy SSL setup
Hi Oskar, Are you using the latest git version? If no, please give it a try, there may be a fix which apply to this case. Baptiste On Thu, Jan 23, 2014 at 12:22 PM, Oskar Liljeblad os...@vergic.com wrote: Hello Our HAProxy 1.5~dev21 setup looks like this: client browser - haproxy1 - haproxy2 - web servers - client browser sends as https. - haproxy1 receives with mode tcp frontend, and sends using mode tcp backend with send-proxy. - haproxy2 receives with mode http frontend with ssl accept-proxy, and sends using mode http backend to web servers. The problem: when clients send a POST requests with 8K payload, the request will appear to hang in the client, and eventually be aborted after 30 seconds. (Our “timeout client” and “timeout server” settings are 30s.) So the client receives no response and I believe HAProxy closes the connection. A workaround/fix for this problem is to set “tune.bufsize 24576” on the second haproxy above (haproxy2). (I assume lowering tune.maxrewrite instead may work as well.) However, the documentation recommends against changing tune.bufsize. And we really don’t want to limit POST payload size. Is this expected behavior? Especially considering that it happens to POST requests and not only GET requests in our setup. Regards, Oskar Liljeblad
RE: tune.bufsize issue with send-proxy / accept-proxy SSL setup
Ah, sorry, I was using the one in Debian (experimental) from 2013-12-17. When I upgraded to 2014-01-18 (1.5~dev21+20140118-1) then the problem did not persist! Thanks for the information! Regards, Oskar -Original Message- From: Baptiste [mailto:bed...@gmail.com] Sent: Thursday, January 23, 2014 12:27 To: Oskar Liljeblad Cc: haproxy@formilux.org Subject: Re: tune.bufsize issue with send-proxy / accept-proxy SSL setup Hi Oskar, Are you using the latest git version? If no, please give it a try, there may be a fix which apply to this case. Baptiste On Thu, Jan 23, 2014 at 12:22 PM, Oskar Liljeblad os...@vergic.com wrote: Hello Our HAProxy 1.5~dev21 setup looks like this: client browser - haproxy1 - haproxy2 - web servers - client browser sends as https. - haproxy1 receives with mode tcp frontend, and sends using mode tcp backend with send-proxy. - haproxy2 receives with mode http frontend with ssl accept-proxy, and sends using mode http backend to web servers. The problem: when clients send a POST requests with 8K payload, the request will appear to hang in the client, and eventually be aborted after 30 seconds. (Our timeout client and timeout server settings are 30s.) So the client receives no response and I believe HAProxy closes the connection. A workaround/fix for this problem is to set tune.bufsize 24576 on the second haproxy above (haproxy2). (I assume lowering tune.maxrewrite instead may work as well.) However, the documentation recommends against changing tune.bufsize. And we really don't want to limit POST payload size. Is this expected behavior? Especially considering that it happens to POST requests and not only GET requests in our setup. Regards, Oskar Liljeblad
memory usage with 1.5dev21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We are running in haproxy 1.5dev21 commit fa7fc95e16fae8b30f2522f59bb945c596e48419. I see very high memory usage just after 5 days. - -- uptime5d 14h 48m children 0 memory kilobytes 1345720 memory kilobytes total1345720 - -- Is this a known problem? cheers thomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS4QrjAAoJEOH/xsXYK8GtYsYP/jAGtHaUrGoDt6r2i3hwsBQy fGanuLYkFcWCWN1sSG4exUOX2o1jJbpkDg1d5fvyTuoBhOhkOBc5JuOcna7EC3Wy 8kgBHe6gIqLaYAfG/2lZ/RX6XhvyJeSUC8JRqAeNIZAmt0gqtAfxujMEn5ES2DM8 3z8/MMTISQdBv/opBeXtOPEARxqkzo3IbjxZUFfxXPBV7tQNiyth6Hhap4A3g505 VQmxaOcNQ65zpQ1X3fAoRHzYqq9pE/AfOPb2Q3zge5hKaEIKH2iD1Zdkmqg+Iqu6 WeLXhJVaehSxT18xfJ2J62tWdxALJoBjof4khHfrhLoSxlvI08ob/GrgjBDHwnAX V++avQl08D83cdLHw0De0ln7NKcug2yltj5OY6gcaah9mzn3CUdQX9P/VaWKIm2e RqNohkk+zwDQNPqUOzF8TJIa8QnoYUHkbuOH4pTzFsMit7hopPRV/AVjkyVN5PRJ cd+1F/D/XlOzplMKz2+nQ/1rZdz4oqqa1sy4RviVeRZCJg+uKdzIs+3q2sXQzRye VJHY4MbHFE+sj+OS/dqHIBL3Vs4HYpCowZA3MM1UsKKfcbayX3XSpt1Gh86bUuGT qRnob6d42ZwnY8nIQDJadpMjSk6h8Gt/2hb3ZG5/pUrY96tt8e9v34nCMbnJl/Et I3SXuzh0gX2FxvHZZgwN =A89l -END PGP SIGNATURE-
Plus Jamais Froid en Hiver
Si ce message ne s'affiche pas correctement consultez-le en ligne Pour être sûr de recevoir nos newsletters, merci d'ajouter notre adresse email bouti...@cgrgolf.fr à vos contacts. www.cgrgolf.fr Rejoignez-nous sur Veuillez me retirer de votre liste de diffusion
Re: memory usage with 1.5dev21
Hi Thomas, Please share your configuration (anonymized). Baptiste On Thu, Jan 23, 2014 at 1:28 PM, Thomas Heil h...@terminal-consulting.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We are running in haproxy 1.5dev21 commit fa7fc95e16fae8b30f2522f59bb945c596e48419. I see very high memory usage just after 5 days. - -- uptime5d 14h 48m children 0 memory kilobytes 1345720 memory kilobytes total1345720 - -- Is this a known problem? cheers thomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS4QrjAAoJEOH/xsXYK8GtYsYP/jAGtHaUrGoDt6r2i3hwsBQy fGanuLYkFcWCWN1sSG4exUOX2o1jJbpkDg1d5fvyTuoBhOhkOBc5JuOcna7EC3Wy 8kgBHe6gIqLaYAfG/2lZ/RX6XhvyJeSUC8JRqAeNIZAmt0gqtAfxujMEn5ES2DM8 3z8/MMTISQdBv/opBeXtOPEARxqkzo3IbjxZUFfxXPBV7tQNiyth6Hhap4A3g505 VQmxaOcNQ65zpQ1X3fAoRHzYqq9pE/AfOPb2Q3zge5hKaEIKH2iD1Zdkmqg+Iqu6 WeLXhJVaehSxT18xfJ2J62tWdxALJoBjof4khHfrhLoSxlvI08ob/GrgjBDHwnAX V++avQl08D83cdLHw0De0ln7NKcug2yltj5OY6gcaah9mzn3CUdQX9P/VaWKIm2e RqNohkk+zwDQNPqUOzF8TJIa8QnoYUHkbuOH4pTzFsMit7hopPRV/AVjkyVN5PRJ cd+1F/D/XlOzplMKz2+nQ/1rZdz4oqqa1sy4RviVeRZCJg+uKdzIs+3q2sXQzRye VJHY4MbHFE+sj+OS/dqHIBL3Vs4HYpCowZA3MM1UsKKfcbayX3XSpt1Gh86bUuGT qRnob6d42ZwnY8nIQDJadpMjSk6h8Gt/2hb3ZG5/pUrY96tt8e9v34nCMbnJl/Et I3SXuzh0gX2FxvHZZgwN =A89l -END PGP SIGNATURE-
Re: memory usage with 1.5dev21
Hi,
On 23.01.2014 16:43, Baptiste wrote:
Hi Thomas,
Please share your configuration (anonymized).
Ive attached the config.
Baptiste
thanks,
thomas
On Thu, Jan 23, 2014 at 1:28 PM, Thomas Heil
h...@terminal-consulting.de wrote:
Hi,
We are running in haproxy 1.5dev21 commit
fa7fc95e16fae8b30f2522f59bb945c596e48419. I see very high memory
usage just after 5 days.
global
maxconn 65000
ulimit-n 65535
uid 0
gid 0
daemon
## tune.pipesize 524288 # only in 1.5
tune.bufsize 33668
tune.maxrewrite 1024
#stats socket /var/run/haproxy.stat level admin
stats socket /var/run/haproxy.stat level admin
nbproc 1
#Loging
#log 172.24.4.39 local0
#log 172.24.4.39 local1 notice
#Logging
cpu-map all 1 2
defaults
maxconn 4
retries 10
option redispatch
no option http-server-close
no option forceclose
option http-keep-alive
option prefer-last-server
option tcp-smart-accept
option tcp-smart-connect
#Logging
log global
#log-format %{+Q}o\ %{-Q}Ci\ -\ -\ [%T]\ %r\ %st\ %B\ \\\ \\\ %Cp\
\%ms\ %ft\ %b\ %s\ \%Tq\ %Tw\ %Tc\ %Tr\ %Tt\ %tsc\ %ac\ %fc\ \%bc\ %sc\ %rc\
%sq\ %bq\ %cc\ %cs\ \%hrl\ %hsl\ \%hr
#Logging
contimeout 15s
clitimeout 30s
srvtimeout 60s
userlist L1
group G1 users tiger,scott
user tiger insecure-password hello groups G1
user scott insecure-password hello groups G1
userlist L2
group G2 users a
user a insecure-password b groups G2
listen app1
bind :8080
mode http
maxconn 200
stats enable
#stats hide-version
stats uri /
#stats auth admin:spawn
#stats admin if TRUE
frontend rtmp-80
bind 1.2.3.92:80
no option forceclose
no option http-server-close
no option http-keep-alive
no option prefer-last-server
mode tcp
maxconn 4000
#Logging
option tcplog
default_backend rtmp-over-http
frontend bread-84
bind 172.24.4.2:84,172.24.4.3:84,172.24.4.4:84,127.0.0.1:84
mode http
#option http-pretend-keepalive
#option forceclose
#option httpclose
option accept-invalid-http-request
reqidel ^X-Forwarded-For:.*
maxconn 2
monitor-uri /haproxycheck
#Logging
log global
option httplog
option logasap
#
# log the name of the virtual server
capture request header Host len 50
capture request header Content-Length len 10
capture request header Accept-Language len 50
capture request header Referer len 200
capture request header User-Agent len 200
capture response header Server len 30
capture response header Content-Length len 10
capture response header Cache-Control len 8
capture response header Via len 20
capture response header Location len 20
capture cookie JSESSIONID len 32
capture response header X-Cache-Hits len 10
capture response header X-Cacheable len 10
capture response header X-Cache len 5
capture response header Content-Encoding len 10
capture response header Cache-Control len 200
capture response header Last-Modified len 200
#Logging
default_backend bk_bread
frontend bread-80-82-varnish
bind
172.24.4.2:82,172.24.4.3:82,172.24.4.4:82,1.2.3.71:82,1.2.3.72:82,1.2.3.73:82,127.0.0.1:82
bind 1.2.3.70:80
#proxy
bind 127.0.0.1:85 accept-proxy id 100
acl ssl-proxy so_id 100
reqidel ^X-Forwarded-For:.*
reqadd x-forwarded-proto:\ https if ssl-proxy
#proxy
mode http
option accept-invalid-http-request
maxconn 2
monitor-uri /haproxycheck
#Logging
log global
option httplog
option logasap
#
capture request header Host len 50
capture request header Content-Length len 10
capture request header Accept-Language len 50
capture request header Referer len 200
capture request header User-Agent len 200
capture response header Server len 30
capture response header Content-Length len 10
capture response header Cache-Control len 8
capture response header Via len 20
capture response header Location len 20
capture cookie JSESSIONID len 32
capture response header X-Cache-Hits len 10
determine size of http headers
What I'd like to do is add a few items to the log line which contain the size of the headers, and then the value of the Content-Length header. This way if the connection is broken for any reason, we can determine if the client sent all the data they were supposed to. Logging the Content-Length header is easy, but I can't find a way to get the size of the headers. The only way that pops into mind is to look for the first occurrence of \r\n\r\n and get its offset (and preferably add 4 as to include the size of the \r\n\r\n in the calculation). But I don't see a way to accomplish this. Any ideas? Thanks -Patrick
Re: updated instructions for tproxy and haproxy
Hi Zach, You can use this link as well: http://blog.exceliance.fr/2013/09/16/howto-transparent-proxying-and-binding-with-haproxy-and-aloha-load-balancer/ Baptiste On Thu, Jan 23, 2014 at 9:11 PM, Buckholz, Zachary zachary.buckh...@pearson.com wrote: I need to forward the client IP for ssh connections to a backend git server. Is the following link still the best source of documentation on how to do this? http://blog.loadbalancer.org/configure-haproxy-with-tproxy-kernel-for-full-transparent-proxy/ Or is there a more upto date method now? Thanks Zach
SIGQUIT, silence
Using haproxy-1.5-dev19 on Debian/Wheezy, and haproxy-1.5-dev21 on CentOS6.2, killing haproxy with SIGQUIT gets me nothing in the system logs. SIGHUP gets proxy/server status info into the logs just fine. I'm using them the same way, but SIGQUIT seems to just do ... nothing? Nut loose on the keyboard? Thanks, ...jfree
Re:RE:MG TV factory from China
Dear Purchasing Manager, How are you ? MG Electronic manufacture Limited Company is one of the top Electronic LCD TV and LED TV,3D TV and Smart TV Manufacturers and Exporters which located in Guangdong province of China. Our main products cover LCD TV from 15~65 inch, LED TV size from 19 inch to 42 inch ,CRT TV from 14~34 inch, LCD monitors from 15~24 inch, 3D TV size from 42-55and other related SKD components. We have more than 10 years of experience in TV development and production. Our products are sold worldwide, including Asia, Europe, Africa, Russia, the Middle East, and South America. Our products have been honored with CE, CB CCC approvals. All of our products are subject to a stringent quality inspection according to customers' requirements. We are doing business on the basic of equality and mutual benefits. It's our desire to continuously satisfy our customers with honesty and creative technology, and we sincerely hope to establish business relationships with customers throughout the world. If you are interested in our products, you are welcome to contact us for more information. With regards Kama ... Company:MG Electronic ManufactureLimited Company Mobile:(0) 152-1725-2928 E-mail:mgtvfact...@163.com Add:Huang pu Industrial area, Qiu chang , Hui Zhui City, Guangdong ,China
