2

I have configured a rule based on the number of IP connections using stick-table with HaProxy such as the following:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    maxconn 60000

backend connectionstablev4
   stick-table type ip size 1m expire 60s store conn_cur

frontend smtpv4
    bind :25

    tcp-request connection track-sc0 src table connectionstablev4
    acl connabuse sc_conn_cur(0,connectionstablev4) gt 5
    
   tcp-request connection reject if connabuse

    # Reject any client that speak before the aloha
    tcp-request inspect-delay 1s
    acl content_present req_len gt 0
    tcp-request content reject if content_present

    default_backend smtp_backend

backend smtp_backend
    mode tcp
    timeout server 1m
    timeout connect 5s

    # Health check
    option smtpchk HELO mx1.improvmx.com

    server srv1 127.0.0.1:2525 check send-proxy maxconn 500

And it works great.

But as soon as I add more processes, like this (in the global section) :

global
    # ... same as above

    nbproc  6
    cpu-map  1 1
    cpu-map  2 2
    cpu-map  3 3
    cpu-map  4 4
    cpu-map  5 5
    cpu-map  6 6

The max connections per IP stops working.

I suspect that the stick-table are per-process basis instead of globally, but I couldn't find any information on that matter.

The issue is clearly with the nbproc/cpu-map because as soon as I remove just this part, everything else works fine.

Is there some rule or configuration to set to indicates HaProxy to use the same stick-table for all the processes?

Thanks in advance.

1 Answer 1

3

Use threads instead of processes. Your problems with processes are mentioned right in the documentation.

https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#3.1-nbthread

This setting is only available when support for threads was built in. It makes haproxy run on threads. This is exclusive with "nbproc". While "nbproc" historically used to be the only way to use multiple processors, it also involved a number of shortcomings related to the lack of synchronization between processes (health-checks, peers, stick-tables, stats, ...) which do not affect threads. As such, any modern configuration is strongly encouraged to migrate away from "nbproc" to "nbthread". "nbthread" also works when HAProxy is started in foreground. On some platforms supporting CPU affinity, when nbproc is not used, the default "nbthread" value is automatically set to the number of CPUs the process is bound to upon startup. This means that the thread count can easily be adjusted from the calling process using commands like "taskset" or "cpuset". Otherwise, this value defaults to 1. The default value is reported in the output of "haproxy -vv". See also "nbproc".

3
  • Awesome, thank you! I followed some article I found online, which mentioned nbproc (probably an old one) ... that's where my troubles begun. Do you know which command I can run to know how many haproxy threads are currently running?
    – Cyril N.
    Apr 27, 2021 at 11:49
  • (or at least a way to know that, without configuration settings, haproxy is using multi threading out of the box, or if I have to configure it). haproxy -vv shows "Built with multi-threading support."
    – Cyril N.
    Apr 27, 2021 at 11:50
  • 1
    to see running threads you can check stats page (cbonte.github.io/haproxy-dconv/2.2/…). it show it like this: ` pid = 7125 (process #1, nbproc = 1, nbthread = 2)` somewhere on top. also via CLI, e.g.: echo 'show info' | socat /var/run/haproxy.sock stdio will show line Nbthread: 2 among others Apr 28, 2021 at 7:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .