Both http & https. Also both web servers started to take it in turns to report as DOWN but more frequently the second one than the first.
I ran ethtool eth0 and can verify that it's full-duplex 1Gbps:
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbag
Wake-on: g
Current message level: 0x00000001 (1)
Link detected: yes
I'm attaching dmesg, I don't understand most of it. I'll try to send a file
in both directions to saturate the link as you suggested.
Thanks again.
On 6 February 2010 12:47, Willy Tarreau <[email protected]> wrote:
> On Sat, Feb 06, 2010 at 12:27:10PM +0100, Peter Griffin wrote:
> > The minute I put the changes and made the loadbalancer active, external
> > users experienced serious downtime. I tried accessing our site from an
> > external source and sure enough we were unbrowsable. So I had to take
> > haproxy off again. Ram was now stable at 750Mb free.
> >
> > At the time I had about 300 connections and only 10% were https.
>
> was it unbrowsable on HTTP too, or just HTTPS ?
>
> > At this point, could it be a defective nic? Wrong kernel? I'm running
> > Fedora 12.
>
> Very unlikely. Hmm would this haproxy run on a dedicated machine ?
> If so, can you check its connectivity ? At least run "ethtool eth0" and
> check that your link is correctly detected as full duplex. If you could
> try a file transfer in each direction to confirm that you can saturate
> the link, it'll be nice.
>
> If the machine is dedicated, it's possible that you have iptables loaded
> too and that it quickly fills its conntrack table. You'd see that in
> "dmesg".
>
> Willy
>
>
dmesg.rar
Description: Binary data
