Hi Gabriel, On Wed, Feb 03, 2010 at 09:39:06PM -0200, Gabriel Sosa wrote: > guys, > > we have customized the 503 and added google analytcs on it to know > how many errors we get. So far we are seeing few errors and I would > like to know if this is because backed servers are full or what. > Also I would like to know if you have any advice for the haproxy > configuration based on the hardware we have because. > > this is our setup: > > we have 2 virtual servers running over a XEN host with apache 2.3 with > 1gb of RAM each > apaches are compiled with prefork and this is the current configuration: > > StartServers 8 > MinSpareServers 5 > MaxSpareServers 20 > ServerLimit 256 > MaxClients 256 > MaxRequestsPerChild 4000
Warning, Apache in prefork mode takes a lot of time to decide to create new processes. If you intend to make it work well, you should start as many servers as you'll need, so set StartServers to 256 to equal MaxClients, and set MaxSpareServers to the same value so that it does not start killing them after some time. > haproxy configuration: > Pentium D930 2gb of RAM > > > global > maxconn 15000 # Total Max Connections. Be careful, while you've set the per-process maxconn here, you have not changed the per-listen one (set it in defaults or listen sections), which is set to 2000 by default. > log 127.0.0.1 local0 > log 127.0.0.1 local1 notice > daemon > nbproc 1 # Number of processes > user haproxy > group haproxy > stats socket /var/run/haproxy.sock mode 666 > > > > defaults > log global > mode tcp > clitimeout 60000 > srvtimeout 18000000 Why this *huge* timeout ??? Do you expect your server to take 5 hours to respond to a request ? This will cause you a lot of trouble if one of the servers suddenly freezes or reboots, because the connections there may remain waiting for that long. > contimeout 15000 > retries 3 > option redispatch > > errorfile 503 /etc/haproxy/errorfiles/503sorry.html > > > listen tracking ZZZ.ZZZ.ZZZ.ZZZ:80 > balance roundrobin > mode http > option forwardfor > option httplog > server www3-tracking XXX.XXX.XXX.XXX weight 1 maxconn 240 check > server www2-tracking YYY.YYY.YYY.YYY weight 1 maxconn 240 check > > > listen load_balanced_http AAA.AAA.AAA.AAA:80 > balance roundrobin > mode http > option forwardfor > option httplog > server www3-http XXX.XXX.XXX.XXX weight 1 maxconn 240 check > server www2-http YYY.YYY.YYY.YYY weight 1 maxconn 240 check > > listen load_balanced_https AAA.AAA.AAA.AAA:443 > balance source > option ssl-hello-chk > mode tcp > option tcplog > server www2-https YYY.YYY.YYY.YYY weight 1 maxconn 240 check > server www3-https XXX.XXX.XXX.XXX weight 1 maxconn 240 check > > > > as you saw the three frontends shares the same backends but the > highest traffic is comming form the "load_balanced_http" frontend. all > backends have 240 as connection limit (pretty next to the "MaxClients" > values on each apache) Then either you think it's wise to share the same connection pools between the two HTTP frontends, and you put them in a single backend with use_backend rules in the frontends, or you think it's better to leave them split and then you'd better try to ensure that you don't over-allocate entries. Maybe you should slightly lower the load_balanced_http maxconns, and set very low values for the two other ones so that the sum remains below 256 ? > Do you think this is a right configuration? I'm a little worried about > these errors because I can't see if the apaches reach the connection > limit and haproxy queue (and hold) the connections until any backed > its free or drops the connection Do you observe queueing on the stats page (or the logs) ? If so, you'll also know by how much. You should also add "option redispatch" in your defaults section, because right now if one of your server dies while trying to establish a connection, the connection will not be retried on the other one, causing a 503. Regards, Willy
