Thanks for your help. The configuration is now back to 5000 maxconn, and Haproxy has been running with this config over the last weekend. The memory footprint is now >1G.
# ps -u nobody u USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND nobody 9103 0.7 3.9 1334192 1291740 ? Ss Jan30 30:03 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid # telnet localhost 1935 show pools Dumping pools usage. Use SIGQUIT to flush them. - Pool pipe (32 bytes) : 5 allocated (160 bytes), 5 used, 3 users [SHARED] - Pool capture (64 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] - Pool channel (80 bytes) : 168 allocated (13440 bytes), 6 used, 1 users [SHARED] - Pool task (112 bytes) : 149 allocated (16688 bytes), 67 used, 1 users [SHARED] - Pool uniqueid (128 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] - Pool connection (320 bytes) : 168 allocated (53760 bytes), 6 used, 1 users [SHARED] - Pool hdr_idx (416 bytes) : 84 allocated (34944 bytes), 2 used, 1 users [SHARED] - Pool session (864 bytes) : 85 allocated (73440 bytes), 3 used, 1 users [SHARED] - Pool requri (1024 bytes) : 21 allocated (21504 bytes), 0 used, 1 users [SHARED] - Pool buffer (16416 bytes) : 168 allocated (2757888 bytes), 6 used, 1 users [SHARED] Total: 10 pools, 2971824 bytes allocated, 111984 used. ---- I've also executed the tcpdump + strace for about 30 seconds. There should be no confidential info, but to be sure, I will send them to you personally. Let me know if I can capture anything else that could be helpful. Thanks! -- Georges-Etienne On Sat, Jan 31, 2015 at 8:40 AM, Willy Tarreau <w...@1wt.eu> wrote: > On Sat, Jan 31, 2015 at 12:59:34AM +0100, Lukas Tribus wrote: > > > The maxconn was set to 4096 before, and after 45 days, haproxy was > > > using 20gigs... > > > > Ok, can you set maxconn back to 4096, reproduce the leak (to at least > > a few gigabytes) and a run "show pools" a few times to see where > > exactly the memory consumption comes from? > > Also, could you please send a network capture of the checks from > the firewall to haproxy (if possible, taken on the haproxy side) ? > It is possible that there is a specific sequence leading to an > improper close (eg: some SSL structs not being released at certain > steps in the handhskake, etc). > > Please use this to take your capture : > > tcpdump -vs0 -pi eth0 -w checks.cap host <firewall-ip> and port > <local-port> > > Wait for several seconds, then Ctrl-C. Be careful, your capture > will contain all the traffic flowing between haproxy and the > firewall's address facing it, so there might be confidential > information there, only send to the list if you think it's OK. > > Ideally, in parallel you can try to strace haproxy during this > capture : > > strace -tts200 -o checks.log -p $(pgrep haproxy) > > Thanks, > Willy > >
