Re: Low performance in solaris 9

From: Willy Tarreau <w#1wt.eu>
Date: Mon, 5 May 2008 23:46:49 +0200


On Mon, May 05, 2008 at 10:05:12PM +0200, Aleksandar Lazic wrote:
> Hi,
>
> On Mon 05.05.2008 08:56, manuelsspace-listas#yahoo.com wrote:
> >Hello List,
> >
> > The -Vd output is:
> >
> >
> >root#sunexplor # ./haproxy -f digitel.cfg -Vd
> >
> >[WARNING]
> >125/093451 (2187) : parsing [digitel.cfg:34]: keyword 'redispatch' is
> >deprecated, please use 'option redispatch' instead.
> >Available polling systems :
> > poll : pref=200, test result OK
> > select : pref=150, test result OK
> >Total: 2 (2 usable), will use poll.
> >Using poll() as the polling mechanism.
>
> Thanks
>
> >The test was stablish as 2 scenarios:
> >a) test using haproxy, 1 client and 1 backend.
> >b) the same client and the same backend but w/out haproxy. In this
> >case, 200 threads x 200 seconds loading 10k html file each time
> >
> >We have observed 100 connection at top load + 100 queue in haproxy
> >console in apache3. I don't know if this is associated to 200 poll
> >available as -Vd display
>
> Nope the 200 is only the event preference.
>
> >Which client?, pylot 1.1, command line mode (http://www.pylot.org)
>
> >Haproxy config:
>
> [snipp]
>
> >maxconn 2000
> >contimeout 5000
> >clitimeout 50000
> >srvtimeout 50000
> >stats enable
>
> [snipp]
>
> >Haproxy
> >will be used internally balancing web services. 300 users expected + up
> >to 100 threads running in a weblogic requesting services or smpp (up to
> >100tps aprox)
>
> Have you some CLOSE_WAITS and/or TIME_WAITS during the test?
>
> What shows
>
> prstat -T -v 1
> vmstat 1
>
> at runtime?

Also, I would add that it's absolutely mandatory to check the system's rlim_fd_cur and rlim_fd_max variables. The default values of 256 concurrent FDs per process are far too low for today's applications, and this is true for haproxy. It would basically limit you to about 120 concurrent connections, which is clearly in the range of what you're observing.

Willy Received on 2008/05/05 23:46

This archive was generated by hypermail 2.2.0 : 2008/05/06 00:00 CEST