Join my network on LinkedIn

LinkedIn Jérôme Féneau requested to add you as a connection on LinkedIn: -- I'd like to add you to my professional network on LinkedIn. Accept invitation from Jérôme Féneau http://www.linkedin.com/e/-xjwbn9-gq93ldu3-61/4jUgeUFR6ihuPb

Re: HAProxy - "504 Gateway Timeout" error.

Willy Tarreau 1wt.eu> writes: > > Hi, > > On Thu, Jul 14, 2011 at 10:21:56AM +, gidot wrote: > > Thanks Willy, > > > > I managed to fix the problem with the log. It's due to my entry in /etc/ > > syslogd.conf. This thread http://www.serverphorums.com/read.php? > > 10,127228,127867 helped m

Re: nbproc>1, ksoftirqd and response time - just can't get it

Are you running irqbalance? It may help distribute network interface interrupts Sent from my iPhone On 18 Jul 2011, at 03:42, Dmitriy Samsonov wrote: > My test setup is three Dell r410 servers (dual Intel(R) Xeon(R) CPU X5650 @ > 2.67GHz - 24 threads total, 128Gb RAM) all connected to 1Gbps n

Re: [PATCH 0/6] Free memory on exit

On Fri, Jul 15, 2011 at 01:14:05PM +0900, Simon Horman wrote: > The motivation for this is that when soft-restart is merged > it will be come more important to free all relevant memory in deinit( All applied, thank you Simon ! Willy

Re: nbproc>1, ksoftirqd and response time - just can't get it

Hi, On Mon, Jul 18, 2011 at 06:42:54AM +0400, Dmitriy Samsonov wrote: > My test setup is three Dell r410 servers (dual Intel(R) Xeon(R) CPU X5650 @ > 2.67GHz - 24 threads total, 128Gb RAM) all connected to 1Gbps network. > > One server is haproxy, configured to block all requests with > 'Accept-

Re: nbproc>1, ksoftirqd and response time - just can't get it

On Mon, Jul 18, 2011 at 08:54:15AM +0100, John Helliwell wrote: > Are you running irqbalance? It may help distribute network interface > interrupts It's often worse for low-latency processing such as haproxy. irqbalance is nice when each interrupt induces very long CPU processing, but here we hav

unsubscribe

subscribe

Thoughts on the master-worker model

Hi Simon ! Last week I could find some time with a quiet place at work to dig again into the master-worker patch series. I went back to what we discussed a few weeks ago concerning the pid management and the cmdline parsing which must be performed only once, until I realized that I was having tro

Re: nbproc>1, ksoftirqd and response time - just can't get it

Hi! 2011/7/18 Willy Tarreau > Hi, > > On Mon, Jul 18, 2011 at 06:42:54AM +0400, Dmitriy Samsonov wrote: > > My test setup is three Dell r410 servers (dual Intel(R) Xeon(R) CPU X5650 > @ > > 2.67GHz - 24 threads total, 128Gb RAM) all connected to 1Gbps network. > > > > One server is haproxy, con

Re: nbproc>1, ksoftirqd and response time - just can't get it

Hi Dmitriy, On Mon, Jul 18, 2011 at 10:01:47PM +0400, Dmitriy Samsonov wrote: > defaults > mode http > maxconn 79500 > timeout client 20s > timeout server 15s > timeout queue 60s > timeout connect 4s > timeout http-request 5s > timeo

haproxy response buffering

Hi all, I am having a similar problem as this guy: http://forums.rightscale.com/showthread.php?t=665 Basically, when sending chunked response, and not ending the connection, haproxy will buffer initial chunks for 3 seconds, after that chunks go out instantly. I tinkered with buffer size settings

Re: haproxy response buffering

Hi, On Mon, Jul 18, 2011 at 11:46:12PM +0300, P.R. wrote: > Hi all, > I am having a similar problem as this guy: > http://forums.rightscale.com/showthread.php?t=665 > > Basically, when sending chunked response, and not ending the connection, > haproxy will buffer initial chunks for 3 seconds, aft

Unreliable soft-restarts on Ubuntu 10.04 with haproxy 1.4.8 and 1.4.15

ssl frontend encoders-in bind 0.0.0.0:3000 default_backend encoders frontend encoders-v2-in bind 0.0.0.0:3002 default_backend encoders-v2 frontend redis-in bind 0.0.0.0:6379 mode tcp default_backend redis # - output of haproxy -vv [20

Re: Unreliable soft-restarts on Ubuntu 10.04 with haproxy 1.4.8 and 1.4.15

On Mon, Jul 18, 2011 at 05:46:55PM -0400, Jonathan Simms wrote: > Hello all, > > I've been tearing my hair out trying to get soft-restarts to work reliably, > and > have been frustrated for about a week solid. I'm running 1.4.15 on Ubuntu > 10.04 > amd64, kernel version 2.6.32-32-generic. > > T

Re: Unreliable soft-restarts on Ubuntu 10.04 with haproxy 1.4.8 and 1.4.15

On Mon, Jul 18, 2011 at 6:06 PM, Willy Tarreau wrote: > On Mon, Jul 18, 2011 at 05:46:55PM -0400, Jonathan Simms wrote: >> Hello all, >> >> I've been tearing my hair out trying to get soft-restarts to work reliably, >> and >> have been frustrated for about a week solid. I'm running 1.4.15 on Ubun

Re: nbproc>1, ksoftirqd and response time - just can't get it

Hi! > > Fine, this is a lot better now. Since you're running at 2000 concurrent > connections, the impact on the cache is noticeable (at 32kB per connection > for haproxy, it's 64MB of RAM possibly touched each second, maybe only 16MB > since requests are short and fit in a single page). Could you

Re: nbproc>1, ksoftirqd and response time - just can't get it

On 7/18/11 5:25 PM, Dmitriy Samsonov wrote: My final task is to handle DDoS attacks with flexible and robust filter available. Haproxy is already helping me to stay alive under ~8-10k DDoS bots (I'm using two servers and DNS RR in production), but attackers are not sleeping and I'm expecting atta

No Attachments Please

You sent an email to the Exchange list with an attachment. We have disabled this option as recently a virus was attached. Please resend your posting without it? Thanks!

Re: Unreliable soft-restarts on Ubuntu 10.04 with haproxy 1.4.8 and 1.4.15

On Mon, Jul 18, 2011 at 06:33:33PM -0400, Jonathan Simms wrote: > Willy, > > I looked at the previous bug report here > http://comments.gmane.org/gmane.comp.web.haproxy/5439 > based on 2.6.38 and checked the ubuntu 2.6.32 kernel for the offending patch >

Re: nbproc>1, ksoftirqd and response time - just can't get it

Hi Dmitriy, On Tue, Jul 19, 2011 at 04:25:29AM +0400, Dmitriy Samsonov wrote: > Using one/two clients with ab2 -c 250 -H 'Accept-Encoding: None' -n (...) >   98%     11 >   99%     13 >  100%   9022 (longest request) Still some drops. Was this before or after ethtool+somaxconn ? > Also I've upgr