当服务Web套接字时，HAProxy正在交换（严重故障）

我观察到我们的HAProxy实例提供了一些networking套接字。目前故障率很低（0.01个主要故障）。我们使用nbproc模式，一个进程用于http处理，另外三个进程专用于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运行）。

我是否应该通过将交换性设置为零来防止这种错误？ 我想这可能是健康的内存pipe理，但也许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 <[email protected]> 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.

configuration片段：

 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

必须绝对防止发生！幸运的是，在太严重之前你才注意到它。

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

正在使用的内存的最大数量约为（（2 * bufsize + 2kB）* maxconn * nbproc）haproxy本身，再加上内核端口的最小约（4 * 4kB * maxconn * nbproc）。

websocket的问题是，连接可能会持续很长时间，并且会堆叠在一起，从而导致比连接非常短的HTTP时更多的压力。您的设置可能会导致内存使用量过高，并且只有WebSocket能够达到这些限制。

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

经过一番挖掘，这里是我发现的：

这个盒子绝对没有任何forms的内存争夺。几乎所有的caching数据都是由映射到haproxy日志文件的页面组成的。由于这些文件不断被写入，并且往往很牛逼，他们会占用大量的caching页面。

当这些日志的磁盘页面被映射时，他们最终将从haproxy中交换出真正的旧匿名页面。所有真正旧的页面恰好属于我们的websocket haproxy，并且它们很可能是来自真正旧连接的缓冲空间。

我已经拒绝了swappiness，所以它不会很积极地交换页面。这应该导致haproxy日志页面被丢弃，而不是haproxy匿名页面被换出。