Haproxy graceful reload

haproxyload balancing

I was looking for a solution for graceful reload of haproxy. I have a nginx server running which passes requests to Haproxy and at times I reload the Haproxy configuration. But I am observing that at time of reloading all the existing connections are getting cut off and haproxy backend queue shows 0 requests ( got from socket stats of haproxy ) .

I am using the method mentioned in several blog posts and haproxy documentation about the issue :

Reload :

haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf (</var/run/haproxy.pid)

Start :

haproxy -D  -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid

It be grateful if someone could suggest any solution. Below is my haproxy config file

global
  maxconn 64000
  ulimit-n 200000
  log             127.0.0.1       local0
  log             127.0.0.1       local1 notice
  spread-checks 5
  stats socket /etc/haproxy/stats

defaults
  log global
  mode http
  balance roundrobin
  maxconn 64000
  option abortonclose
  option httpclose
  retries 3
  option redispatch
  timeout client 30000
  timeout connect 30000
  timeout server 30000
  stats enable
  stats uri     /haproxy?stats
  stats realm   Haproxy Statistics
  stats auth    haproxy:stats
  timeout check 5000

Best Answer

The command you posted does not seem 100% correct to me. On my system, it reads:

haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf $(cat /var/run/haproxy.pid)

You mistyped the value of last option -sf.

Related Solutions

Ssl – HaProxy – Http and SSL pass through config

What are you using to cipher/decipher the SSL traffic before haproxy ? Stunnel, nginx, apache, something else ?

I suspect it might be related to the lack of "option httpclose" on your port 80, but it's not clear to me why it would cause an issue to only a few visitors.

HAProxy: Display a “BADREQ” | BADREQ’s by the thousands

Your timeouts are too low. Increase them.

timeout connect 30s
timeout client  30s

The absolute minimum is 5 seconds for traffic between two servers in the same rack. A TCP connection takes 3 seconds to open if there is any packet loss, which invariably happens from time to time.

The minimum timeout is 15 seconds to support international traffic, like a client from Australia connecting to a server in North America. There is quite a high latency and low bandwidth in some locations in the world, much worse than one would expect. Being reasonable on timeouts is a prerequisite to do business worldwide.

The minimum timeout is 30 seconds to support mobile connections and poor reception WiFi. It's unreliable connectivity that can and do experience short periods of blackout.

Keep in mind. Timeouts are meant to handle the worst case scenario of connectivity and they should only catch truly failed connections. They could be set somewhat shorter but this has no benefit except generating errors on clients and servers, which is not a benefit.

Consider that a periodic request made every 5 seconds, something as simple as a healthcheck or a polling API, is actually as much as 17280 requests per day. Thus a good timeout setting should cause less than 0.01% of false positives or it's creating errors every day for no reason.

88500 Sessions and 4500 errors in the last 20 minutes.

That's 5% of errors. It's a very high error rate.

Considering that the average webpage takes more than 20 sub requests to load, it means that every single page on your site is failing to load partially.

Related Topic