Hi Will, I didn't see my post in the archives and since this is a production site I panicked.
Thank you so much for your explanation, it's much clearer now. I will make the changes and report back how it went. Do you think that I'd be better off upgrading to 4Gb Ram or should 1Gb be enough? Cheers On 6 February 2010 09:21, Willy Tarreau <[email protected]> wrote: > Hi Peter, > > it's needless to resend your mail 3 times. Most people on this list aren't > always available, but are generally helpful. Sometimes you just have to be > a bit patient. > > I see no timeout in your stunnel configuration : > > > My stunnel.conf: > > #setuid=stunnel > > #setgid=proxy > > > > debug = 3 > > output = /var/log/stunnel.log > > > > socket=l:TCP_NODELAY=1 > > socket=r:TCP_NODELAY=1 > > > > [https] > > accept=10.0.1.50:443 > > connect=10.0.1.50:80 <http://10.0.1.50/> <http://10.0.1.50/> > > TIMEOUTclose=0 > > xforwardedfor=yes > > That means that each time a visitor suddenly gets off the net, > you end up with an ever-lasting connection. Those connections > pile up, until stunnel cannot accept any more. It's very likely > the problem you're observing. The problem is even amplified by > the fact that apparently you're doing some NAT in front of stunnel, > leaving almost no chance for out of state packets to trigger a > possible RST. Please set the following ones to reasonable values > (eg: 30-60 seconds) : TIMEOUTbusy, TIMEOUTidle. This one should > also be specified even if less important since its the same > machine : TIMEOUTconnect. > > Also, eventhough that's unrelated, I suggest that your replace : > "option forwardfor" with "option forwardfor except 10.0.1.50" in > your haproxy config. That way, connections coming from stunnel > will have the stunnel's x-forwarded-for header last. And those > coming from everywhere else will have haproxy's. That means that > your server will always have the client's IP in the last header. > > Also, I don't know if the 45 Mbps you were talking about are full > SSL traffic, but in this case you might want to be very careful > about setting limits so that stunnel's connections do not go > through the roof. I think the only way to do that with stunnel is > by setting ulimit before launching it, though I'm not certain. > > Hoping this helps, > Willy > >
