the problem got serious so I stood up another LB set of instances and installed v1.3.23 all traffic is getting routed over to it.
what I used to see in the logs where just NOSRV 503 in the haproxy log once it hit max con. Now that we upgraded (or rather migrated) let me see if the issue continues or another one presents itself. so far so good but no burst yet. Most likely "Everything worked once I upgraded" will be the result (isn't it always), but thanks for the quick response as always. On Wed, Mar 3, 2010 at 2:23 PM, Willy Tarreau <[email protected]> wrote: > Hi Joe, > > On Wed, Mar 03, 2010 at 01:30:50PM -0500, Joe Stein wrote: > > Hi All, anyone have any ideas if this is something in version bug (do not > > want to upgrade if not) or is something I can control with configuration. > > > > So what I see running haproxy is when there are bursts (an additional > lets > > say 1,000 connections) i get NOSRV from all of my backend servers. > > > > I set all of the max conn to a VERY low number (as a test) to confirm > that > > the downstream servers were not causing this. They can handle this load > > without spikes so when the spikes come haproxy goes screwey. > > > > I am not opposed to upgrading (currently runngin v 3.19) but need some > solid > > ground that doing so will fix this issue if possible any assistance is > > welcome. > > I suspect that you have a low "timeout queue" (which defaults to "timeout > connect" if unset) which aborts the requests from the queue when the > timeout > is expired. What do your log look like when you get this ? Probably the > flags > start with "sQ" or something like this indicating the request was aborted > in > the queue while waiting for a server. > > Willy > > -- /* Joe Stein, 973-944-0094 http://www.medialets.com */
