Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm new to haproxy, and using it for TCP load balancing of rsyslog logs to ArcSight connectors. For the life of me, I cannot get traffic to evenly balance across all of the nodes in the pool (which is the desired behavior). I've tried many permutations of weights and maxconn's to no avail.

It feels like this should be an easy problem, but the per pool node behaviors are very confusing. Also, since most people use haproxy for http load balancing, I'm finding scant documentation about the best way to go about what I am trying to do.

Anyone have any insights, proven configs, or troubleshooting steps to recommend?


Here is our current config:

    log       local0
    log       local1 notice
    maxconn 256000
    user haproxy
    group haproxy
    spread-checks 5

    log global
    option dontlognull
    option redispatch
    option allbackups
    maxconn 256000
    timeout connect 5000

listen stats :1936
    mode http
    stats enable
    stats realm Haproxy\ Statistics
    stats uri /
    stats auth admin:savetheday

frontend rsyslog_netscreen
    mode tcp
    option tcplog
    option contstats
    option tcpka
    default_backend rsyslog_netscreen_backend

backend rsyslog_netscreen_backend
    balance roundrobin
    mode tcp
    option tcpka
    option srvtcpka
    server netscreen1 localhost:9515 weight 1 maxconn 1024 check
    server netscreen2 localhost:9516 weight 1 maxconn 1024 check
    server netscreen3 localhost:9517 weight 1 maxconn 1024 check
    server netscreen4 localhost:9518 weight 1 maxconn 1024 check
    server netscreen5 localhost:9519 weight 1 maxconn 1024 check
    server netscreen6 localhost:9520 weight 1 maxconn 1024 check
share|improve this question

Note that roundrobin is not a good strategy to achieve even load. It will make sure that each backend receives the same number of connections over time, but does not care how long each connection last.

In your stats view, it should be apparent that the total number of sessions per backend server is almost equal (if their uptimes are equal). The number of current sessions can vary quite a bit, though.

We have found that using leastconn instead of roundrobin yields a much more even load. This makes sense, because servers that happen to be stuck with many long-lived clients that hold on to their connection need not be burdened with new incoming connections.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.