HAProxy 在为 Web 套接字提供服务时正在交换（主要故障）

Question

我在我们的 HAProxy 实例中观察到一些交换，该实例为 Web 套接字提供服务。目前故障率较低（0.01 大故障/s）。我们使用 nbproc 模式，其中一个进程用于 http 处理，另外 3 个进程专用于 SSL 处理。

从 Perf，我能够从 http 处理实例中获取以下故障样本：

 Samples: 36  of event 'page-faults:u', Event count (approx.): 206
 28.64%  haproxy-t3  haproxy       [.] si_conn_wake_cb
 20.87%  haproxy-t3  haproxy       [.] si_conn_recv_cb
 13.11%  haproxy-t3  haproxy       [.] raw_sock_to_buf
 10.68%  haproxy-t3  haproxy       [.] stream_int_chk_snd_conn
  7.28%  haproxy-t3  haproxy       [.] conn_fd_handler
  4.37%  haproxy-t3  haproxy       [.] http_end_txn
  3.88%  haproxy-t3  haproxy       [.] stream_int_update_conn
  3.88%  haproxy-t3  haproxy       [.] process_session
  2.91%  haproxy-t3  haproxy       [.] eb_delete
  2.43%  haproxy-t3  haproxy       [.] stream_sock_read0
  1.94%  haproxy-t3  libc-2.12.so  [.] __memset_sse2

由于这保持了相当数量的并发连接，内存使用量相当高（所有实例约 16 GB（因为我们正在运行，总共有 4 个nbproc）。

我是否应该尝试通过将 swapiness 设置为零来防止这种故障？我认为这可能是健康的内存管理，但也许 haproxy 永远不应该真正交换？

参考数据：

这台机器上的内存开销：

[root@ny-lb06 ~]# free -m
             total       used       free     shared    buffers     cached
Mem:         64375      58876       5499          0         86      34472
-/+ buffers/cache:      24317      40058
Swap:         6015        267       5748

版本信息：

HA-Proxy version 1.5.2 2014/07/12
Copyright 2000-2014 Willy Tarreau <w@1wt.eu>

Build options :
  TARGET  = linux26
  CPU     = generic
  CC      = gcc
  CFLAGS  = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing
  OPTIONS = USE_GETADDRINFO=1 USE_REGPARM=1 USE_OPENSSL=1 USE_STATIC_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built without zlib support (USE_ZLIB not set)
Compression algorithms supported : identity
Built with OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013
Running on OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with transparent proxy support using: IP_TRANSPARENT IP_FREEBIND

Available polling systems :
      epoll : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

配置片段：

global
    maxconn 300000
    tune.bufsize 16384
    nbproc 4

所有 HAProxy 实例的内存（注意 haproxy-t3 是我们的套接字服务器实例，是交换的实例）：

[root@ny-lb06 ~]# ps -A -o cmd,vsz,rss,pid
/opt/haproxy/haproxy-t3 -D  8424224 8299192 30343
/opt/haproxy/haproxy-t3 -D  2259988 2185768 30344
/opt/haproxy/haproxy-t3 -D  3079456 3013344 30345
/opt/haproxy/haproxy-t3 -D  2445524 2380072 30346
/opt/haproxy/haproxy-t4 -D   93332 27780 31606
/opt/haproxy/haproxy-t4 -D   61108  2988 31607
/opt/haproxy/haproxy-t4 -D   61232  3132 31608
/opt/haproxy/haproxy-t4 -D   61288  7464 31609
/opt/haproxy/haproxy-t2 -D   66572 14216 32497
/opt/haproxy/haproxy-t2 -D   63308 12052 32498
/opt/haproxy/haproxy-t2 -D   66400 15696 32499
/opt/haproxy/haproxy-t2 -D   64168 12592 32500
/opt/haproxy/haproxy-t20 -D  57400  5268 33284
/opt/haproxy/haproxy-t20 -D  59620  3864 33285
/opt/haproxy/haproxy-t20 -D  59640  6176 33286
/opt/haproxy/haproxy-t20 -D  59620  3928 33287
/opt/haproxy/haproxy-t1 -D  805556 750948 34693
/opt/haproxy/haproxy-t1 -D  189860 137264 34694
/opt/haproxy/haproxy-t1 -D  196988 144472 34696
/opt/haproxy/haproxy-t1 -D  187136 134524 34697
/opt/haproxy/haproxy-t5 -D   59464  7368 41065
/opt/haproxy/haproxy-t5 -D   59756  1772 41066
/opt/haproxy/haproxy-t5 -D   59984  2136 41067
/opt/haproxy/haproxy-t5 -D   59756  4240 41068

Answer 1

必须绝对防止这种情况发生！幸运的是你在它太严重之前就注意到了。

请在全局部分检查您的 maxconn，检查您是否在全局部分使用“tune.bufsize”（否则您可以假设为 16kB），并检查进程数。

haproxy 本身的最大使用内存量约为 ((2*bufsize + 2kB) * maxconn * nbproc)，内核端套接字的最小值约为 (4 * 4kB * maxconn * nbproc)。

websocket 的问题在于，连接可以持续很长时间并且堆叠在一起，导致比在连接非常短的情况下执行 HTTP 时产生更大的压力。您的设置可能会占用过高的内存，并且只有 WebSocket 能够达到这些限制。

顺便说一句，我在这台机器上看到了 34 GB 的缓存，所以它可能是真正的缓存（在这种情况下您不必担心）或 /dev/shm 中的临时数据。另外，你能检查一下你的haproxy进程的VSZ和RSS吗？