我观察到在我们的HAProxy实例中交换一些服务于Web套接字的实例.目前故障率很低(0.01主要故障/秒).我们使用nbproc模式,一个进程用于http处理,另外三个进程专用于SSL处理.
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).
我是否应该尝试通过将交换设置为零来防止此错误？我认为这可能是健康的内存管理,但也许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
解决方法
必须绝对防止发生！幸运的是,在它太严重之前你已经注意到了它.
请检查全局部分中的maxconn,检查是否在全局部分中使用“tune.bufsize”(否则可以假设为16kB),并检查进程数.
对于haproxy本身,使用的最大内存量约为((2 * bufsize 2kB)* maxconn * nbproc),加上内核端套接字的最小值约为(4 * 4kB * maxconn * nbproc).
websocket的问题在于连接可以持续很长时间并且堆叠在一起导致比在连接非常短的HTTP时更多的压力.您的设置可能允许过高的内存使用量,并且只有WebSocket能够达到这些限制.
顺便说一句,我在这台机器上看到了34 GB的缓存,所以它可能是真正的缓存(在这种情况下你不必担心)或/ dev / shm中的临时数据.另外,您可以查看您的haproxy进程的VSZ和RSS吗？
