BTW, I've also just run siege as root, thinking I might have been hitting my own ulimit somehow (my ulimit -n was set to 1024 which seemed all too coincidental :). This didn't make any difference, alas.

-Fred Leeflang

On 09/28/2012 06:01 AM, Fred Leeflang wrote:
Hello,

I have set up haproxy on two virtual (Xen) machines, listening to two virtual IP addresses (heartbeat).

It's loadbalancing nginx, varnish, memcache, php-fpm and mysql and functionally it works. I seem to be running into some sort of resource limitation however; When I run siege on the website it always ends up saying:

siege aborted due to excessive socket failure; you
can change the failure threshold in $HOME/.siegerc
Transactions:                1038 hits
Availability:               50.34 %
Elapsed time:                5.26 secs
Data transferred:            8.24 MB
Response time:                0.07 secs
Transaction rate:          197.34 trans/sec
Throughput:                1.57 MB/sec
Concurrency:               14.05
Successful transactions:        1038
Failed transactions:            1024
Longest transaction:            1.04
Shortest transaction:            0.01

The number of failed transactions and the number of transactions is always the same.

I've tweaked the kernel with some things I've found on the net:

net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_fin_timeout = 3
net.ipv4.tcp_tw_recycle = 0
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_no_metrics_save=1
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.ip_nonlocal_bind=1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65023
net.ipv4.tcp_max_tw_buckets = 400000

I've included my config as well.

Any ideas as to what I have forgotten about that makes the system run out of resources here? I can't find anything in the syslog that indicates any problems. It might be the Xen host logs anything but have not checked that yet, or it may also be the BSD firewall (in front of these two haproxy servers) that runs out of resources but haven't checked those yet as I'd first like to get my haproxy setup checked.

Thanks,
Fred Leeflang


Reply via email to